Add commands for screencasting by lutien · Pull Request #1069 · w3c/webdriver-bidi

lutien · 2026-02-06T16:09:12Z

Closes #636.

Introduce the interface to record a video of the screen of the provided navigable and save it to a file.

~~The PR for the hook in the Screen Capture specification: w3c/mediacapture-screen-share#328.~~

The PR for the hook in the Viewport Capture specification: w3c/mediacapture-viewport#34.

jgraham · 2026-02-06T18:12:40Z

+
+1. Let |media recorder options| be a struct with <code>mimeType</code> |mime type|.
+
+1. Let |media recorder| be a new {{MediaRecorder}} with {{MediaRecorder/stream}} |media stream| and


This feels somewhat sketchy in that it is invoking a lot of JS machinery without being clear about which realm it's operating it.

Ok, I've added the logic to create MediaRecorder and Blob in the navigable's realm. But since I couldn't really find a similar case in the BiDi spec, I had to improvise with the wording :) So feel free to correct me

nvborisenko · 2026-02-07T11:05:15Z

Command versus events... From client side perspective it doesn't make sense to just browsingContext.StartScreencast, in any case a client needs to provide a handler for events. Just a proposal to think about: what if it would be regular event pattern.. I subscribe (actually starting screencast on remote end), and handle events data.

So instead of (pseudo programming language):

var scr = browsingContext.startScreencast(new Options { frameRate: 5 })
browsingContext.on('screencastDataReceived', e => doSomething())
scr.stopScreencast()

We can do the following:

var scr = browsingContext.on('screencastDataReceived', new Options { frameRate: 5 }, e => doSomething())
scr.unsubscribe()

For a client startScreencast method seems just as enabler for event's data, why not to try to reuse events modelling in this case? I understand it requires to review existing model, and allow some additional arguments when subscribing. And it is good! We already have a possibility to provide userContext or browsingContext when subscribing. I can imagine the following example where it can be useful: network.beforeRequestSent event is raised for all requests.. would be nice if I can listen to only "**/*.png" requests.

…hey are camera specific.

lutien · 2026-02-09T15:13:33Z

@nvborisenko, the current idea for the screencast API is to start with commands to record the video and save it to a file (sorry, it was probably not very clear, I've updated the PR description now). And for this interface, we need start and stop commands. The next step would be to introduce the streaming option. In that case we probably will just pass a different type to the start command to indicate that we want to get a stream, then the command will return some handle that can be used to read the stream (see #1061). So we actually do not currently plan to introduce the event-based interface, but even if we decide to do this in the future, I guess I would see it as another type for startScreencast command. You can check the minutes from the last group discussion here: #636 (comment).

Co-authored-by: Maksim Sadym <69349599+sadym-chromium@users.noreply.github.com>

juliandescottes

I can only provide limited feedback. From my point of view it sounds reasonable.

Co-authored-by: Julian Descottes <jdescottes@mozilla.com>

lutien · 2026-02-20T16:44:58Z

For the visibility, in the PR for the getDisplayMedia hook, there is a proposal to move the hook to https://www.w3.org/TR/mediacapture-viewport/#capturing-viewport-media, which is basically a subset of getDisplayMedia to work only with top-level browsing context, so it should be easier to integrate. That sounds reasonable to me, so I'm going to move it there.

nvborisenko · 2026-02-20T19:41:07Z

+      }
+
+      browsingContext.MediaStreamOptions = {
+         ? video: bool / browsingContext.MediaTrackConstraints .default true;


It is hard for strongly typed languages. boolean or object? I propose to avoid it early. Kind of #1039, but in this case it is even harder.

This is the type structure from https://w3c.github.io/mediacapture-main/#dom-mediastreamconstraints, and we use this spec as a base for these APis. I understand that it doesn't look very elegant, but I'm not sure why it's difficult to implement for strongly typed languages. We have the same type definitions for, e.g., getDisplayMedia in our C++ code. For #1039 I can see that some languages don't have the mechanism to distinguish between null and undefined, but as far as I know, usually the languages have some way to specify the union type.

whimboo · 2026-02-23T08:26:42Z

which is basically a subset of getDisplayMedia to work only with top-level browsing context, so it should be easier to integrate. That sounds reasonable to me, so I'm going to move it there.

Is there a reason why we only want to allow recording of a screencast for a top-level browsing context? We do not have this restriction for capturing a screenshot and I can see use cases when consumers only want to record a frame.

lutien · 2026-02-23T09:10:20Z

Is there a reason why we only want to allow recording of a screencast for a top-level browsing context? We do not have this restriction for capturing a screenshot and I can see use cases when consumers only want to record a frame.

There is no support for recording a video of a frame in getDisplayMedia and, as far as I know, there is no other WebRTC API currently to do that. I think CDP also only supports that (maybe @OrKoN or @sadym-chromium can correct me if I'm wrong). In my opinion it's fine as a start, and we can add it in the future if/when the support on the WebRTC side will be added.

sadym-chromium · 2026-02-23T10:50:37Z

Is there a reason why we only want to allow recording of a screencast for a top-level browsing context? We do not have this restriction for capturing a screenshot and I can see use cases when consumers only want to record a frame.

It is unlikely that Chromium will support nested browsing contexts' screencasts. I would make a decision based on the following:

If there are other vendors who are going to support "nested browsing contexts' screencasts" AND there is a requirement from the clients for that, then add it into the spec.
Otherwise leave the main spec tight for the top-level browsing contexts. If a single vendor wants to implement it, they can extend the command with vendor-specific parameter (like moz:nestedBrowsingContext or something) to implement it.

…a browser tab".

lutien · 2026-02-24T16:46:42Z

All comments should be addressed. The new link for the external hook PR is w3c/mediacapture-viewport#34 (also updated in the PR description).

jan-ivar

Thanks for working on this!

I have some questions to aid review in w3c/mediacapture-viewport#34.

jan-ivar · 2026-03-16T21:24:51Z

+1. Let <var>realm</var> be the result of [=trying=] to [=get a realm from a navigable=]
+   with |navigable id| and null.
+
+1. Let |promise| be the result of [=trying=] to [=capture a browsing context viewport=] with


It's not just the promise but the returned MediaStream object and its embedded MediaStreamTrack objects for video and audio we need to consider. All four are JS objects given no realm to live in.

From handle an incoming message it seems remote end steps all run in parallel:

So there's no JS set up here yet AFAIU. How are you planning on using these objects? From JS or c++?

jan-ivar · 2026-03-16T21:38:02Z

+      1. Let |realm| be result of [=trying=] to [=get or create a sandbox realm=] given
+         |screencast| and |navigable|.


Is this the destination realm for the promise, its stream, and tracks? If so, perhaps we can pass it into the capture algorithm earlier?

jan-ivar · 2026-03-16T22:05:18Z

+      1. Let |media recorder| be a new {{MediaRecorder}} in |realm|
+         with {{MediaRecorder/stream}} |media stream| and
+         {{MediaRecorderOptions}} |media recorder options|.
+
+      1. Let |recording| be a new [=screencast recording=] with
+         [=screencast recording/mediaRecorder=] |media recorder|,
+         [=screencast recording/path=] |path|,
+         [=screencast recording/size=] 0.
+
+      1. Whenever the implementation is going to [=fire a blob event=] named {{MediaRecorder/dataavailable}}
+         at |media recorder| with |blob|, run the following steps:


Is there a precedent for this approach in some other command?

I'm not super familiar with WebDriver-BiDi and sandbox realms, but it's surprising to me to see JS-facing APIs used in this way in parallel. I'd normally associate this with data races. These JS objects are being created on the navigable being captured? What thread do their constructors run on?

Is this the long-term plan?

If yes, passing in the realm to the capture algorithm earlier might work

If no, might adding automation steps to https://w3c.github.io/mediacapture-record be another approach to ultimately try to pass around non-JS objects here?

Is there a precedent for this approach in some other command?

I think the answer is "not really".

Historically WebDriver has managed to call into algorithms that are written entirely in terms of abstract spec objects. In browser terms this is roughly equivalent to native code (i.e. C++ or similar).

However as we add more modern platform features we're more frequently running into cases where the spec itself assumes that it's being called from executing script, and is written in terms of operations on JS objects. That obviously makes sense if the only entry point is via scripting interfaces defined in WebIDL, but a WebDriver endpoint is not that.

A current idea I have is to create a agent/environment settings object/realm that's defined in the WebDriver spec and is only used for running spec-internal code, somewhat similar to parent process JS in Firefox. I asked about this idea on matrix, but so far no one gave any feedback on whether that was a silly idea…

So the plan is to have two options for this command:

save the MediaStream into the file (what is this PR about now);

stream the MediaStream over the websocket to the client (after we introduce the general streaming support with Add io module for streams #1061).

So I think we still need to get out of me capture a browsing context viewport at least the MediaStream. I guess we could try to resolve the promise on the capture a browsing context viewport side, but I'm not sure if it would make it easier.

…ding in the specification execution environment.

jgraham · 2026-03-17T10:43:03Z

+      1. Let |media recorder| be a new {{MediaRecorder}} in |realm|
+         with {{MediaRecorder/stream}} |media stream| and
+         {{MediaRecorderOptions}} |media recorder options|.
+
+      1. Let |recording| be a new [=screencast recording=] with
+         [=screencast recording/mediaRecorder=] |media recorder|,
+         [=screencast recording/path=] |path|,
+         [=screencast recording/size=] 0.
+
+      1. Whenever the implementation is going to [=fire a blob event=] named {{MediaRecorder/dataavailable}}
+         at |media recorder| with |blob|, run the following steps:


Is there a precedent for this approach in some other command?

I think the answer is "not really".

Historically WebDriver has managed to call into algorithms that are written entirely in terms of abstract spec objects. In browser terms this is roughly equivalent to native code (i.e. C++ or similar).

However as we add more modern platform features we're more frequently running into cases where the spec itself assumes that it's being called from executing script, and is written in terms of operations on JS objects. That obviously makes sense if the only entry point is via scripting interfaces defined in WebIDL, but a WebDriver endpoint is not that.

A current idea I have is to create a agent/environment settings object/realm that's defined in the WebDriver spec and is only used for running spec-internal code, somewhat similar to parent process JS in Firefox. I asked about this idea on matrix, but so far no one gave any feedback on whether that was a silly idea…

…aRecorder and add the issue.

OrKoN · 2026-04-07T11:03:57Z

+
+   Issue: The specification execution environment has to be better defined.
+
+1. [=Prepare to run script=] with |environment settings|.


Can we specify it without requiring the implementations to run scripts?

The problem we have is that we want to call existing platform APIs that assume in their specification that they're being called from a WebIDL interface which can only be invoked when running script. So they do things like use promises, whose sematics are undefined outside of the context of JS execution. If we don't use that model we have to reimplement the entire API with different semantics

My plan is to have a "specification agent" which allows us to run script in a way that's invisible to the content process, and is basically only a specification formalism. Implementations will be free to not actually run script as long as the observable behaviour is correct.

OrKoN · 2026-04-07T12:59:41Z

+         {{MediaRecorderOptions}} |media recorder options|.
+
+      1. Let |recording| be a new [=screencast recording=] with
+         [=screencast recording/mediaRecorder=] |media recorder|,


Can we save objects like |media recorder| across navigations? I thought media recorder would be bound to a specific realm?

@jgraham @lutien do you think we can rewrite this spec proposal without using promises / IDL / requiring a JS execution context? it looks like in the media viewport the relevant portion of the spec is https://w3c.github.io/mediacapture-viewport/#dom-mediadevices-getviewportmedia (step 10.3)? And then it just becomes a MediaStream from IDL? Perhaps we could link to the constraints defined by the spec and eventually make a WebDriver BiDi stream out of it re-using the stream spec algorithms.

The provided media MUST include precisely one video track, which MUST be a live-capture of the [browser](https://www.w3.org/TR/screen-capture/#dfn-browser) [display surface](https://www.w3.org/TR/screen-capture/#dfn-display-surface) of the [relevant global object](https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global)'s [associated Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#concept-document-window)'s [top-level browsing context](https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-browsing-context)'s [viewport](https://html.spec.whatwg.org/multipage/#viewport). The provided media MUST include at most one audio track, which, if provided, MUST be the combined audio produced by the sum of documents that consist of the [relevant global object](https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global)'s [associated Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#concept-document-window)'s [top-level browsing context](https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-browsing-context)'s [active document](https://html.spec.whatwg.org/multipage/document-sequences.html#nav-document), and all [active documents](https://html.spec.whatwg.org/multipage/document-sequences.html#nav-document) in nested [browsing context](https://html.spec.whatwg.org/multipage/document-sequences.html#browsing-context)s of the [relevant global object](https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global)'s [associated Document](https://html.spec.whatwg.org/multipage/nav-history-apis.html#concept-document-window)'s [top-level browsing context](https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-browsing-context). This audio track MUST NOT be included if audio was not specified in requestedMediaTypes, or if it was specified as false. The source of a [MediaStreamTrack](https://www.w3.org/TR/mediacapture-streams/#dom-mediastreamtrack) MUST NOT change. If the result of the request is "[granted](https://www.w3.org/TR/permissions/#dom-permissionstate-granted)", then for each device that is sourcing the provided media, using a stable and private id for the device, deviceId, set [[devicesLiveMap]][deviceId] to true, if it isn’t already true, and set the [[devicesAccessibleMap]][deviceId] to true, if it isn’t already true. The user agent MUST NOT store a "[granted](https://www.w3.org/TR/permissions/#dom-permissionstate-granted)" permission entry.

It looks like MediaStream is supposed to live in some JS execution context as well (see comment here: #1069 (comment)). I've created a draft PR with an attempt to sketch something without requiring JS: #1113. I've used some working from https://w3c.github.io/mediacapture-viewport/, which we could potentially share, but mostly it's just abstract describing, since I couldn't really find the way to share more with other specs.

Thanks! I guess if we had #1061 (comment) specified without JS execution realms we could just use WebDriver BiDi's own stream instead of MediaStream?

From what I've understood (tagging @jgraham to correct me/clarify), it still might be an issue for working with the streams, because the stream algorithms are really determined that they are running JS.

Do we have a conclusion here? I think it would be nice to avoid JS for specifying this and I think maybe we can specify our own stream behavior that also does not rely on running JS?

So to unblock things, we decided to focus on #1113, but only for saving screencasting to the file for now. And then come back to the streaming option after we're more certain about the generic streaming API. We were planning to talk about it on Wednesday, but we can discuss it now if you have any feedback already.

That sounds good to me, should I review https://github.com/w3c/webdriver-bidi/pull/1113/changes?

Sure (I thought it would be good to review internally first, to save you the trouble. But if you have time, I guess there is no point in delaying 🙂 ).

css-meeting-bot · 2026-04-08T16:18:10Z

The Browser Testing and Tools Working Group just discussed Reminder to review the PR for screencasting API.

The full IRC log of that discussion

<AutomatedTester> Topic: Reminder to review the PR for screencasting API
<AutomatedTester> github: https://github.com//pull/1069
<orkon> q+
<AutomatedTester> jdescottes: This is a reminder to review the PR from sasha. Sasha is on PTO at the moment, please raise questions and we will answer to the best of our ability
<AutomatedTester> ack next
<jgraham> q+
<AutomatedTester> orkon: I've been trying to prototype this and there web content API has been quite hard to use and there is nothing about stitching things so would need to be invited
<AutomatedTester> ... but building it off web apis isn't doable
<AutomatedTester> ... are there restrictions to what format needs to be output or is that up to the implementation
<AutomatedTester> ack next
<AutomatedTester> jgraham: I don't know what web rtc has but that format is likely the best
<AutomatedTester> ... the other question has...
<AutomatedTester> ... with web apis there is an idea that you are calling it from a IDL context which assumes javascript etc
<AutomatedTester> ... we have a similar issue with the streams API
<AutomatedTester> ... but when I suggested using something not using JS on streams the editor told me that wouldn't work as it would need a way of resolving promises
<AutomatedTester> ... we would likely need to have a "specification realm" that is not a content realm and is something else
<AutomatedTester> ... and it spec "fiction". It's like running script but not exactly like running a script <gives an example>
<AutomatedTester> ... in Firefox this is easier and we know that doesn't mean much as in other browsers it could be a C++ type call
<AutomatedTester> ... that's my best idea but if we don't do that then we are in a difficult position
<orkon> q+
<AutomatedTester> ... it then becomes a very handwavy way doing "capture this and then output that with web rtc"
<AutomatedTester> ... and it becomes unclear what realms this should run in
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> orkon: thanks for the explaination. THis seems to work well for streams but I am not sure that works for screencast
<jgraham> q+
<AutomatedTester> ... but I might not have fully read those spec. The main thing is that we don't depend of the side effects of javascript execution other than the algorithm itself
<AutomatedTester> ack next
<AutomatedTester> jgraham: I need to look to see if this would work. parts of it works well but as a whole maybe not. THere might be a possiblity is that this is very complicated. We also have a way in the future that we can stream the browser not the file what we are currently thinging about
<AutomatedTester> q?

Co-authored-by: François Daoust <fd@tidoust.net>

…nition.

OrKoN · 2026-04-23T14:10:46Z

+      }
+
+      browsingContext.MediaTrackConstraints = {
+         ? width: js-uint,


how are width / height parameters used by the underlying spec? Is it something to scale the output to or is it mix/max constraint for the stream selection? I do not seem to find mentions of it (same for timeslice).

width and height are supposed to be used for scaling. You can see more info here: https://www.w3.org/TR/screen-capture/#constrainable-properties. timeslice is used as a parameter for MediaRecorder.start(timeslice) (spec: https://w3c.github.io/mediacapture-record/#dom-mediarecorder-start)

OrKoN · 2026-05-04T09:03:08Z

+        context: browsingContext.BrowsingContext,
+        mimeType: text,
+        ? streamOptions: browsingContext.MediaStreamOptions,
+        ? timeslice: js-uint .default 1000


to confirm: the timeslice only controls the size of the chunks but does not affect the framerate? Do we need to expose timeslice in this case? (we just write to file right and with the stream API the client would probably determine the size of the chunks).

Yes, that's right. It's only required to define when to write to a file (if we want to write while recording), and I agree we don't really have to expose it.

Since we do not have the dedicated event for this, I think clients would have difficulty to extract chunks of the right timeslice duration from the file. I would suggest we remove timeslice and leave it to be implementation -defined and instead we add a framerate that would be very useful for clients?

Sounds good. I've updated the PR to make timeslice an implementation-defined and added frameRate to the video constraints.

OrKoN · 2026-05-04T13:45:55Z

+
+      browsingContext.StartScreencastParameters = {
+        context: browsingContext.BrowsingContext,
+        mimeType: text,


wdyt to make mimeType optional to mean implementation-defined default mime type?

I think that should be fine. Updated the PR ✅

Add commands for screencasting

4c58bff

jgraham reviewed Feb 6, 2026

View reviewed changes

lutien added 3 commits February 9, 2026 13:37

Await on the promise returned from "capture a browser tab".

6bdfd0e

Create MediaRecorder and Blob in navigable's window realm.

55bcbcc

Remove "facingMode" and "backgroundBlur" from "streamOptnios" since t…

b0d2460

…hey are camera specific.

lutien force-pushed the add-screencasting-commands branch from d0b4832 to b0d2460 Compare February 9, 2026 14:07

sadym-chromium reviewed Feb 13, 2026

View reviewed changes

Comment thread index.bs Outdated

sadym-chromium reviewed Feb 13, 2026

View reviewed changes

Comment thread index.bs Outdated

Comment thread index.bs Outdated

Comment thread index.bs Outdated

lutien and others added 2 commits February 13, 2026 17:32

Update index.bs

2da09c5

Co-authored-by: Maksim Sadym <69349599+sadym-chromium@users.noreply.github.com>

Limit "browsingContext.MediaTrackConstraints".

28d45b4

juliandescottes reviewed Feb 19, 2026

View reviewed changes

Comment thread index.bs Outdated

Comment thread index.bs

OrKoN reviewed Feb 19, 2026

View reviewed changes

Comment thread index.bs Outdated

OrKoN reviewed Feb 19, 2026

View reviewed changes

Comment thread index.bs Outdated

Update index.bs

00a0094

Co-authored-by: Julian Descottes <jdescottes@mozilla.com>

nvborisenko reviewed Feb 20, 2026

View reviewed changes

lutien mentioned this pull request Feb 24, 2026

Add an algorithm for the browser automation. w3c/mediacapture-viewport#34

Open

lutien added 4 commits February 24, 2026 15:26

Use "capture a browsing context viewport" algorithm instead "capture …

f8c150c

…a browser tab".

Add "size" to the "browsingContext.stopScreencast" return result.

d60f8bc

Write to the file while recording the screencast

e779925

Stop screencast media recorders during a session cleanup

b2d6c41

lutien commented Feb 24, 2026

View reviewed changes

Comment thread index.bs Outdated

sadym-chromium reviewed Feb 24, 2026

View reviewed changes

Comment thread index.bs

Use linkable definition in "screencast recordings map".

47af858

Create sandbox for MediaRecorder.

eae5706

lutien requested a review from jgraham March 10, 2026 13:14

jan-ivar reviewed Mar 16, 2026

View reviewed changes

Run "Prepare to run script" to initialize the JS for screencast recor…

ed19972

…ding in the specification execution environment.

jgraham reviewed Mar 23, 2026

View reviewed changes

Use "the specification execution environment" realm to work with Medi…

cb35b0c

…aRecorder and add the issue.

nvborisenko mentioned this pull request Mar 23, 2026

[🚀 Feature]: [dotnet] [bidi] Finalize public API to prevent further breaking changes SeleniumHQ/selenium#16095

Open

15 tasks

OrKoN reviewed Apr 7, 2026

View reviewed changes

tidoust reviewed Apr 8, 2026

View reviewed changes

Comment thread index.bs Outdated

tidoust reviewed Apr 8, 2026

View reviewed changes

Comment thread index.bs Outdated

Comment thread index.bs Outdated

Comment thread index.bs Outdated

OrKoN reviewed Apr 13, 2026

View reviewed changes

Comment thread index.bs Outdated

lutien and others added 2 commits April 14, 2026 12:09

Remove unneeded spec imports

3d63dce

Co-authored-by: François Daoust <fd@tidoust.net>

Add back "is type supported" import

7902a5a

lutien force-pushed the add-screencasting-commands branch from cb1f040 to 7902a5a Compare April 14, 2026 10:09

Use the correct syntax for an autolink to the "abstract-op"-type defi…

d500592

…nition.

OrKoN reviewed Apr 22, 2026

View reviewed changes

Comment thread index.bs Outdated

OrKoN reviewed Apr 23, 2026

View reviewed changes

Comment thread index.bs

lutien mentioned this pull request Apr 23, 2026

Alternaitve proposal for screencasting commands without JS primitives #1113

Merged

lutien added 2 commits April 23, 2026 18:21

Don't allow video parameter being disabled.

21ab432

Don't validate mimeType

a8a90a0

OrKoN reviewed May 4, 2026

View reviewed changes

lutien added 3 commits May 4, 2026 18:17

Do not expose "timeslice" as a parameter

d77a6d6

Add "frameRate" parameter to "browsingContext.startScreencast".

0518ea8

Make "mimeType" parameter optional

b8241ec

lutien force-pushed the add-screencasting-commands branch from e327cc0 to b8241ec Compare May 4, 2026 16:17

lutien marked this pull request as draft May 15, 2026 12:24


		1. Let \|media recorder options\| be a struct with <code>mimeType</code> \|mime type\|.

		1. Let \|media recorder\| be a new {{MediaRecorder}} with {{MediaRecorder/stream}} \|media stream\| and

		1. Let \|realm\| be result of [=trying=] to [=get or create a sandbox realm=] given
		\|screencast\| and \|navigable\|.


		Issue: The specification execution environment has to be better defined.

		1. [=Prepare to run script=] with \|environment settings\|.

Conversation

lutien commented Feb 6, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nvborisenko commented Feb 7, 2026

Uh oh!

lutien commented Feb 9, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

juliandescottes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lutien commented Feb 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

whimboo commented Feb 23, 2026

Uh oh!

lutien commented Feb 23, 2026

Uh oh!

sadym-chromium commented Feb 23, 2026

Uh oh!

Uh oh!

lutien commented Feb 24, 2026

Uh oh!

Uh oh!

jan-ivar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lutien commented Feb 6, 2026 •

edited by pr-preview Bot

Loading