Refine srcObject's MediaSourceHandle behavior by wolenetz · Pull Request #306 · w3c/media-source

wolenetz · 2022-03-31T18:19:16Z

Current description of this PR:
Overall intent for a MediaSourceHandle is that it should be
[Transferable], and be restricted to "at most one" successful attachment
to the underlying MediaSource by a handle. Further, if a Window
MediaSource was previously attached using a legacy MSE object URL,
subsequent attempts to use that MediaSource instance's
MediaSourceHandle for attachment must also fail.

Changes MediaSource.getHandle() to be a [SameObject] readonly attribute named handle.
Adds HTMLMediaElement.srcObject extension subsection.
Updates MediaSourceHandle transfer and related attachment text to more
clearly indicate that transferring a handle prevents re-transfer of
that instance due to the [[Detached]] internal slot's logic, and that
transfer is also synchronously prevented if the handle instance's
[[has ever been assigned as srcobject]] internal slot is true. Also
adds multiple notes to describe intent and to clarify.
Updates the "attaching to a media element" text to indicate that a
MediaSourceHandle can be attached successfully to at most one media
element ever.
Note that legacy MSE object URL attachments similarly already achieve
the same intent in existing implementations. This change includes a
clarification for MSE object URL attachments, since it was never the
intent even for main-thread MediaSource attachments for them to be
successfully attached to more than one HTMLMediaElement at a time.
The switch to more clear srcObject usage for worker MSE attachment
affords the spec an opportunity to be more clear about this intent.

This refinement originates from discussion on the previous PR with
@karlt (#305) and from lengthy
discussion on this change itself at
#306.

This work is associated with the MSE-in-Worker spec issue:
#175

Original description of this PR (updated more recently per #306 (comment)):

Adds text intending to help prevent using one or more
MediaSourceHandle for the same underlying MediaSource for
simultaneous, concurrent attachments to media elements:

Updates MediaSource.getHandle() to succeed at most once per
MediaSource instance.
Updates MediaSourceHandle transfer section to more clearly indicate
that transferring a handle out of a context makes that handle
unavailable for transferring again out of the same context (unless it
is first transferred back to that context).
Updates the "attaching to a media element" text to indicate that a
MediaSourceHandle can be attached successfully to at most one media
element at a time, and with the previous 2 clarifications, ensures
that the underlying worker context MediaSource can only be attached
successfully to at most one media element at a time.

Note that legacy MSE object URL attachments similarly already achieve
the same intent in existing implementations. This change includes a
clarification for those similar to the third bullet, but for a
MediaSource in the "attaching to a media element" text, since it was
never the intent even for main-thread MediaSource attachments for them
to be successfully attached to more than one HTMLMediaElement at a
time. The switch to more clear srcObject usage for worker MSE
attachment affords the spec an opportunity to be more clear about this
intent.

This refinement originates from discussion on the previous PR with
@karlt: #305

This work is associated with the MSE-in-Worker spec issue:
#175

Preview | Diff

wolenetz · 2022-03-31T18:23:54Z

@mwatson2, please review. Also, @karlt, please take a look to ensure I've addressed the issues we discussed in #305.

Thank you!

karlt

I'm not clear on the best way to deal with a transfer of the MediaSourceHandle while it is set on a srcObject attribute. Alternatives to consider:

Allow the transfer and error on the media element.
Block transfer while on the srcObject attribute.
The "transfer steps" caller is expecting a possible exception from DetachArrayBuffer(transferable) in the [[ArrayBufferData]] case, so I guess "transfer steps" could also throw an exception.
Set [[Detached]] to true and transfer the underlying MediaSource reference "during setup worker attachment communication".
This approach might be tricky to extend to the scenario of unsetting from this media element attribute and setting on another media element.
Transfer the underlying MediaSource reference in the srcObject setter and transfer back when unset.

There is a slight difference in timing of options 3 and 4 due to awaiting stable state in the resource selection algorithm, and either of these timings could be applied to option 2.

karlt · 2022-03-31T23:32:15Z

media-source-respec.html

+            <dt>If the media provider object is a {{MediaSourceHandle}} or a {{MediaSource}} that is already being used
+              beyond this point as the media provider object in a different {{HTMLMediaElement}}'s
+              <a def-id="resource-fetch-algorithm"></a></dt>
+            <dd>Run the <a def-id="media-data-cannot-be-fetched"></a> steps of the <a
+                def-id="resource-fetch-algorithm"></a>'s <a def-id="media-data-processing-steps-list"></a>.</dd>
+            <dt>If {{MediaSource/readyState}} is NOT set to {{ReadyState/""closed""}}</dt>
+            <dd>Run the <a def-id="media-data-cannot-be-fetched"></a> steps of the <a
+                def-id="resource-fetch-algorithm"></a>'s <a def-id="media-data-processing-steps-list"></a>.</dd>


Having the same kind of error path, as you describe, for multiple attachments of a single MediaSource, regardless of whether from Window or Worker context, makes sense.

If a MediaSourceHandle's [[Detached]] slot is true, then would this same path be taken?
(Consider transfer out of this Window context.)
If so, then explicitly saying here would be helpful.
But the decision here may depend on the choice of direction with the transfer-while-attached scenario.

I guess the alternative is to throw in the srcObject setter, but there is no precedent for that.

Thank you for your analysis and presentation of options. While I think each of those options are viable, I like options 1 and 2 best. They seem to be the simplest in concept and in implementation complexity. For option 1, the resulting MediaError.message could more readily indicate the reason for the error in that case. What are the timing considerations you mentioned might apply to option 2?

Note that initial prototype implementation in Chrome might just forgo some of the complexity involved in allowed sequential re-use of the same MediaSourceHandle (and add that later). The app can always create one or more extra MediaSource instances in the worker and get those handle(s) over to the main thread for readiness to use later as a workaround in the interim.

Consider the following two commands running under the same event (i.e. without a stable state between them):

video.srcObject = handle; port.postMessage(null, [handle]);

With option 4, the postMessage() would fail and the video would keep playing.
With option 3, [[Detached]] is not set to true until the next stable state, and so the postMessage() would succeed and the video would error.

Option 2 may be spec'd by marking the handle as in use either in the srcObject setter for similar behavior to option 4 or in the "setup worker attachment communication" steps for similar behavior to option 3.

I haven't looked into the when exactly the handle would become unused if unset from srcObject, so there may be similar timing issues there for

video.srcObject = null; // previous value was handle port.postMessage(null, [handle]);

Perhaps option 1 is immune to these subtleties.

@ #306 (comment) :

I haven't looked into the when exactly the handle would become unused if unset from srcObject, so there may be similar timing issues there for. [...]

Examining the current html5 spec, upon setting srcObject, synchronous execution of the media element load algorithm is done, which has a step that synchronously detaches MediaSource if one is the current assigned media provider object. So it seems that an implementation could readily know on the main/window thread whether or not a particular MediaSourceHandle object is currently assigned to any HTMLMediaElement as srcObject.

Ah, yes. Thanks for identifying that.
So, if choosing to block transfer while in use (i.e. not option 1), then for some consistency with main-thread MediaSource detach, I guess a postMessage() should succeed immediately after a handle is unset through srcObject.

@karlt, yes, I think I would prefer that.
I discussed this during today's Media Working Group Call, and also have shared this thread on the media WG mailing list to get wider input.
Previously, my preference was option 2 (throw exception if currently in use as srcObject value), however I have just now observed an issue with that option (perhaps this is what you were trying to point out, too):

video.srcObject = handle; port.postMessage(null, [handle]);

While the handle is immediately set to be the media element's assigned media provider object, the synchronous portion of this setter (which runs the load algorithm, which then starts the resource selection algorithm) begins the actual attachment in an asynchronous set of steps once the next stable state has been reached. Therefore, the postMessage transfer mechanism, invoked synchronously before that stable state has been reached, does not know that handle is in a state preventing transfer. So neither option 3 or 4 can enable option 2 to prevent transfer before that stable state has been reached.

Does this mean option 2 is infeasible? Maybe, unless we update the srcObject setter spec for when a MediaSourceHandle is set as the assigned media provider object in the synchronous section of the steps following that assignment (for example, in the load algorithm). If we did that, then we could reliably know when the handle is assigned (or not) at any attempt to transfer it. (Note, unsetting the handle as assigned media provider object is already synchronously running MSE detachment as I noted earlier today.)

Overall, my preference is to lean towards giving application synchronous awareness of failure to transfer due to handle being in-use as srcObject already. I think this would help web authors avoid having to debug additional asynchronous error transitions that are already quite overloaded with various kinds of HTMLMediaElement and MSE errors.

I agree that, if choosing to block transfer while in use, then marking the handle as in use synchronously from the srcObject setter would produce the behavior with probably the least surprise.

@ #306 (comment) :
Examining the current html5 spec, upon setting srcObject, synchronous execution of the media element load algorithm is done, which has a step that synchronously detaches MediaSource if one is the current assigned media provider object.

FWIW I was assuming this detach was for the old/previous assigned media provider object. Perhaps that was intended, but that's not what the spec currently says. The srcObject setter "must set the element's assigned media provider object to the new value, and then invoke the element's media element load algorithm.", so the media element load algorithm detaches the new MediaSource object.

Still a synchronous release of the handle from in use when cleared from srcObject would be the least surprise behavior here.

karlt · 2022-03-31T23:38:46Z

media-source-respec.html

+        <p class="note">For example, once a worker transfers a {{MediaSourceHandle}} to another context, it cannot
+        transfer that handle again unless the another context first transfers it back to the worker. This prevents
+        ability to clone {{MediaSourceHandle}} objects and helps prevent simultaneous attachment to distinct media
+        elements using handles to the same underlying {{MediaSource}}.</p>


The [[Detached]] internal slot provides single transfer for us, so your choice as to whether to have additional text here or not.

wolenetz · 2022-06-01T19:45:43Z

The intent is to prevent making more than one usable copy of a MediaSourceHandle for each MediaSource. Transfer semantics restrictions may not be sufficient, since basic serialization without transfer might be attempted.

I propose trying something like this (adding to my current rough prototype in Chrome):

Change MediaSourceHandle to be just "Serializable" (https://html.spec.whatwg.org/multipage/structured-data.html#serializable-objects)
For the serialization steps for MediaSourceHandle:
- if the instance has already been serialized (e.g. some internal slot like [[AlreadySerialized]] is true), then throw exception.
- Similarly, if forStorage is true, then throw exception.
- If this instance is currently set as srcObject on any HTMLMediaElement, then throw exception. Note that this requires extension of HTMLMediaElement's srcObject setter synchronously update a handle internal slot, e.g., [[CurrentlyAttached]] to be true during setting srcObject to the handle (including resetting that slot to be false first for the previous srcObject if that object were also a handle.
- Otherwise, serialize the internal state of the instance, set the instance's [[AlreadySerialized]] true. Note that this internal slot's value is reset false on the new instance resulting from deserialization.

Hopefully this adds clarity to the intent. I'll now try updating the Chrome prototype to do this and see how it goes and respond further here. @karlt and others, if you see any blockers or concerns, please report them here ASAP. Thanks!

wolenetz · 2022-06-01T20:33:21Z

e.g., [[CurrentlyAttached]] to be true during setting srcObject to the handle (including resetting that slot to be false first for the previous srcObject if that object were also a handle.

Note the HTMLMediaElement.srcObject setter doesn't have option to throw exception, but we need to synchronously let the handle know it's in the process of starting a load even before the asynchronous load operation starts. We also need to be careful to protect against the following situation:

// On main thread, handle is initially an unattached MediaSourceHandle
// just received from the worker that owns the underlying MediaSource.

media_element1.srcObject = handle;

// Would throw exception now, since handle is CurrentlyAttached:
// worker.postMessage(handle); 

// But this cannot throw exception. Rather, the mediasource attachment
// steps should later run the failure steps for media_element2:
media_element2.srcObject = handle;

// The following demonstrates that [[CurrentlyAttached]] cannot be a
// boolean since if it were, it would have been doubly set on the
// assignment of |handle| to media_element2, above:
media_element2.srcObject = null;
worker.postMessage(handle);  // If boolean, this would succeed, but shouldn't.

Based on that example, I propose changing [[CurrentlyAttached]] to be a counter
that is incremented when the handle is set to a srcObject on an HTMLMediaElement,
and decremented when the handle is explicitly unset from a srcObject on an
HTMLMediaElement. The attachment steps can then just fail if this value is not
precisely 1, and the serialization steps could throw exception if this value is not
precisely 0.

karlt · 2022-06-01T20:41:49Z

The intent is to prevent making more than one usable copy of a MediaSourceHandle for each MediaSource. Transfer semantics restrictions may not be sufficient, since basic serialization without transfer might be attempted.

I propose trying something like this (adding to my current rough prototype in Chrome):
* Change MediaSourceHandle to be just "Serializable" (https://html.spec.whatwg.org/multipage/structured-data.html#serializable-objects)

While I assume it is possible to specify a serialize-once behavior, I always thought of such a behavior where the object becomes unusable after message passing to fit better with the [Transferable] concept rather than [Serializable].

"Transferring is effectively recreating the object while sharing a reference to the underlying data and then detaching the object being transferred."

Serialization "allows them to be stored on disk and later restored".

Was there a benefit to making the object [Serializable] rather than [Transferable]?

wolenetz · 2022-06-01T20:44:41Z

Was there a benefit to making the object [Serializable] rather than [Transferable]?

Mostly this was due to the existing Chrome transferable infrastructure is clunky and might not do the required transfer steps in a completely interoperable order (from my brief reading).
Secondly, this simplifies postMessage to be just serialization, not making developers also put the object in a transfer list.
The conditional failure if "forStorage" part of the serialization steps allows prevention of usage for other purposes.

wolenetz · 2022-06-01T20:49:20Z

Regarding the specific postMessage exception:
If [[CurrentlyAttached]] > 0 or if [[AlreadySerialized]] is true, then a postMessage attempt including that handle should throw exception. If this condition is found first among other items being posted, then the exception should be a DataCloneError.

wolenetz · 2022-06-01T21:56:37Z

I've updated the chromium prototype change for this (circa patch set 28):

handle copying disallowed. serialization of an instance can happen at most once (but can post a handle back and forth, assuming not currently attached).
srcObject setter decrements previous handle (if any) attachment counter, and increments new handle (if any) attachment counter.
loading steps in HTMLMediaElement do failure steps if loading via the handle and the attachment counter isn't precisely 1.
Note: sequential use of the same handle in the same media element (or unset on one and set on another) fails on subsequent attempts, similarly to what might happen if attempting to load a revoked mediasource object URL.
Note: the prototype doesn't yet disable dedicated worker MSE object URL creation, but that is the next part I'll add before getting it reviewed for landing in Chromium (along with tests).

I've tested the basic scenarios manually and it seems to be working.

wolenetz · 2022-06-01T22:17:01Z

@jernoble @karlt - I plan to proceed with getting the prototype in Chromium landed in parallel with updating this PR per the details as of #306 (comment)
Please raise any concerns you might have ASAP to prevent further delay on this highly-desired feature. Thanks!

wolenetz · 2022-06-02T00:02:05Z

@jernoble @karlt - I plan to proceed with getting the prototype in Chromium landed in parallel with updating this PR per the details as of #306 (comment)
Please raise any concerns you might have ASAP to prevent further delay on this highly-desired feature. Thanks!

Thanks to @sandersdan I am now aware of potential further complications:
It may not be interoperable to prevent postMessage(handle) from creating more than one handle, since this might actually be implicitly a broadcast on some implementations or on implementations where extensions might get a copy of messages. Achieving true move semantics is not possible. As a result, the window thread might eventually have multiple distinct handles referencing internally the same underlying worker-thread-owned MediaSource. It falls to the implementation to prevent simultaneous attachments (during the asynchronous media element load algorithm) from proceeding successfully, allowing at most 1 of them to attach successfully.
tldr: Keeping the [[IsAlreadySerialized]] proposed internal slot is not sufficient to prevent copies, but does help early detection of some of those scenarios. The media element load algorithm must fail if the same underlying MediaSource is already not 'closed'. The latter isn't a change to the spec.
Overall, Serializable is simpler ergonomically than Transferable, especially when there is potential for underlying broadcast or lack of true move semantics.

karlt · 2022-06-03T05:16:42Z

Browser implementations are free to use different approaches if they can produce the same observable behavior. Extensions can modify behavior in any way the browser lets them, if they are prepared to expect consequences, so browsers can't expect to maintain interoperable behavior in the presence of arbitrary extensions.

But what behavior would content see from passing a MediaSourceHandle to BroadcastChannel#postMessage(), if it were serializable?

While merely transferable and not serializable, MediaSourceHandle cannot be transferred through BroadcastChannel, which is consistent with transfer of MessagePort. "transferring does not make sense in multi-destination situations." MessagePort is similar to MediaSourceHandle in that it is a transferable object used for two-directional message-passing communication between threads and processes.

sandersdan · 2022-06-03T18:35:08Z

browsers can't expect to maintain interoperable behavior in the presence of arbitrary extensions.

As I understand it, all major browser implement the same behavior for message posting, which is broadcasting to all content script realms.

In WebCodecs we wanted to be able to have move semantics for VideoFrame but this detail made it impossible to implement in practice.

The situation with MediaSourceHandle is simpler because the resources it holds are less scarce, but I do want to recommend against inventing a new model for object ownership. If you don't follow the JS-like path (cloneable objects that are GC'd), there are surprising roadblocks.

But what behavior would content see from passing a MediaSourceHandle to BroadcastChannel#postMessage(), if it were serializable?

I would recommend that each receiver gets a valid handle, and that all valid handles are invalidated when one is attached.

While merely transferable and not serializable, MediaSourceHandle cannot be transferred through BroadcastChannel, which is consistent with transfer of MessagePort.

I don't think this is an option. Transferable isn't its own concept (or even an IDL attribute any more), it's a detail of the structured clone algorithm. If you can't serialize it, you can't transfer it either.

If there is a way to accomplish this combination, note that it would also prevent passing these handles through a TransferableStream.

wolenetz · 2022-06-03T18:52:57Z

I would recommend that each receiver gets a valid handle, and that all valid handles are invalidated when one is attached.

I agree. Further, for a particular handle instance, if it has ever been assigned to an HTMLMediaElement srcObject (even if the subsequent asynchronous load was interrupted and the underlying MediaSource hadn't ever been attached successfully), then that handle instance can never be successfully serialized again.

However, I think instantaneous serialization prevention of any handle instance in any realm with the same underlying MediaSource (such multiple instances can happen if extensions/broadcasts cause clones of the original single handle retrieved from MediaSource.getHandle()) upon any of those handles ever being assigned as srcObject to an HTMLMediaElement would risk security (could enable malicious high-resolution timer attacks).

So I think the following may be the best approach. If we find later that these restrictions can be relaxed, we can update the spec and implementations further:

prevent a handle instance from being serialized if either it has already been serialized or if it has ever been assigned as srcObject to an HTMLMediaElement (regardless of whether or not that actually resulted in successful attachment+load)
prevent the underlying MediaSource from being used (successfully loaded) more than once via srcObject on any HTMLMediaElement (similar to the existing object URL attachment mechanism immediately revoking the object URL on attachment start).

Adds core MediaSourceHandle interface and modules implementation. Later changes will enable apps to get a handle from a dedicated worker MediaSource, post it to the main thread and attach it to an HTMLMediaElement via the srcObject attribute; they will also include test updates. References: Full prototype CL: https://chromium-review.googlesource.com/c/chromium/src/+/3515334 MSE spec issue: w3c/media-source#175 MSE spec feature updates switching from worker MSE attachment via object URL to attachment via srcObject MediaSourceHandle: * w3c/media-source#305 * further clarifications in discussion at w3c/media-source#306 (comment) BUG=878133 Change-Id: I9a3b47ea02d2755a9860999e245eafc26f864977 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3687146 Commit-Queue: Matthew Wolenetz <[email protected]> Reviewed-by: Kentaro Hara <[email protected]> Reviewed-by: Dale Curtis <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012115}

Adds ability for apps to get a MediaSourceHandle from a dedicated worker MediaSource instance, gated by RuntimeEnabledFeature "MediaSourceInWorkersUsingHandle". Updates the PassKey required for creation of a concrete MediaSourceAttachmentSupplement to allow that only from either URLMediaSource::createObjectURL or the new MediaSource::getHandle method. This specificity is enabled by a new AttachmentCreationPassKeyProvider type. Later changes will enable apps to post the handle to the main thread and attach it to an HTMLMediaElement via the srcObject attribute; they will also include test updates. References: Full prototype CL: https://chromium-review.googlesource.com/c/chromium/src/+/3515334 MSE spec issue: w3c/media-source#175 MSE spec feature updates switching from worker MSE attachment via object URL to attachment via srcObject MediaSourceHandle: * w3c/media-source#305 * further clarifications in discussion at w3c/media-source#306 (comment) crbug.com/506273 is somewhat related, but not fixed by this change (it refers to directly setting MediaSource on Window context to the media element's srcObject attribute.) This change sequence is specific to enabling MSE-in-Worker attachment via srcObject using a handle object. BUG=878133,506273 Change-Id: Ic61f4cc4193080bdbc39234b98897d9a789778d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688613 Commit-Queue: Matthew Wolenetz <[email protected]> Reviewed-by: Will Cassella <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012129}

Adds ability to serialize a MediaSourceHandleImpl, conditionally failing with DataCloneError if the handle is_serialized() already or if the handle is_used() (both of those are initialized to be false in the new instance created during deserialization.) Later changes will enable apps to attach the handle to a main thread HTMLMediaElement via the srcObject attribute; they will also include test updates. References: Full prototype CL: https://chromium-review.googlesource.com/c/chromium/src/+/3515334 MSE spec issue: w3c/media-source#175 MSE spec feature updates switching from worker MSE attachment via object URL to attachment via srcObject MediaSourceHandle: * w3c/media-source#305 * further clarifications in discussion at w3c/media-source#306 (comment) BUG=878133 Change-Id: I19cc8a450423964aef78e8e468776e8cd912503a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688599 Reviewed-by: Will Cassella <[email protected]> Reviewed-by: Kentaro Hara <[email protected]> Commit-Queue: Matthew Wolenetz <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012132}

Adds ability to attach a dedicated-worker-owned MediaSource to an HTMLMediaElement using a MediaSourceHandle for that MediaSource instance that the app has posted over to the main thread and assigned to the srcObject attribute on the media element. Previously, only a MediaStream could be set as a srcObject in Chrome. This change adds the relevant MediaProvider IDL union type and makes it the type of that srcObject attribute. For historical reasons, the srcObject attribute of an HTMLMediaElement is implemented in modules as a partial interface; this change updates that partial interface as well as the media element implementation to enable the scenario without regressing existing ability to use MediaStream as media element's srcObject. The attachment of the worker MediaSource using the handle does not involve lookup into a URL registry; rather, an internal blob URL is built into the handle when it was retrieved from the MediaSource and that URL is used to satisfy existing media element load safety checks as well as provide the underlying WebMediaPlayer a URL that it can use when logging to devtools. Later changes will add further test updates and remove the previous ability to attach a worker MediaSource using a registered object URL. References: Full prototype CL: https://chromium-review.googlesource.com/c/chromium/src/+/3515334 MSE spec issue: w3c/media-source#175 MSE spec feature updates switching from worker MSE attachment via object URL to attachment via srcObject MediaSourceHandle: * w3c/media-source#305 * further clarifications in discussion at w3c/media-source#306 (comment) crbug.com/506273 is somewhat related, but not fixed by this change (it refers to directly setting MediaSource on Window context to the media element's srcObject attribute.) This change sequence is specific to enabling MSE-in-Worker attachment via srcObject using a handle object. BUG=878133,506273 Change-Id: I86cddd87bafae1c7cbae9e94ea4614418067012f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688740 Reviewed-by: Kentaro Hara <[email protected]> Reviewed-by: Elad Alon <[email protected]> Reviewed-by: Dale Curtis <[email protected]> Commit-Queue: Matthew Wolenetz <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012202}

If the MediaSourceInWorkersUsingHandle feature is enabled, this change prevents successful ability of obtaining an objectURL that would succeed in loading a worker-owned MediaSource. It changes the wpt tests to use handle for attachment and verifies expected new behavior of getHandle and that worker objectURL attachment fails (these tests run on experimental builds of Chromium with currently-experimental MediaSourceInWorkersUsingHandle feature enabled, just like the currently-experimental MediaSourceInWorkers feature.) References: Full prototype CL for the parts 1-4 that have already landed: https://chromium-review.googlesource.com/c/chromium/src/+/3515334 MSE spec issue: w3c/media-source#175 MSE spec feature updates switching from worker MSE attachment via object URL to attachment via srcObject MediaSourceHandle: * w3c/media-source#305 * further clarifications in discussion at w3c/media-source#306 (comment) BUG=878133 Change-Id: I60ddca79ee0f95c87b6d84e4f44ad9c283f359a3

If the MediaSourceInWorkersUsingHandle feature is enabled, this change prevents successful ability of obtaining an objectURL that would succeed in loading a worker-owned MediaSource. It changes the wpt tests to use handle for attachment and verifies expected new behavior of getHandle and that worker objectURL attachment fails (these tests run on experimental builds of Chromium with currently-experimental MediaSourceInWorkersUsingHandle feature enabled, just like the currently-experimental MediaSourceInWorkers feature.) References: Full prototype CL for the parts 1-4 that have already landed: https://chromium-review.googlesource.com/c/chromium/src/+/3515334 MSE spec issue: w3c/media-source#175 MSE spec feature updates switching from worker MSE attachment via object URL to attachment via srcObject MediaSourceHandle: * w3c/media-source#305 * further clarifications in discussion at w3c/media-source#306 (comment) BUG=878133 Change-Id: I60ddca79ee0f95c87b6d84e4f44ad9c283f359a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3698231 Commit-Queue: Matthew Wolenetz <[email protected]> Auto-Submit: Matthew Wolenetz <[email protected]> Reviewed-by: Will Cassella <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012712}

…bjectURL" This reverts commit 6315549. Reason for revert: This is causing failures on the WebKit Linux Leak builder i.e. https://ci.chromium.org/ui/p/chromium/builders/ci/WebKit%20Linux%20Leak/39394/overview Original change's description: > MSE-in-Workers: srcObject part 5: Conditionally fail worker objectURL > > If the MediaSourceInWorkersUsingHandle feature is enabled, this change > prevents successful ability of obtaining an objectURL that would succeed > in loading a worker-owned MediaSource. > > It changes the wpt tests to use handle for attachment and verifies > expected new behavior of getHandle and that worker objectURL attachment > fails (these tests run on experimental builds of Chromium with > currently-experimental MediaSourceInWorkersUsingHandle feature enabled, > just like the currently-experimental MediaSourceInWorkers feature.) > > References: > Full prototype CL for the parts 1-4 that have already landed: > https://chromium-review.googlesource.com/c/chromium/src/+/3515334 > MSE spec issue: > w3c/media-source#175 > MSE spec feature updates switching from worker MSE attachment via > object URL to attachment via srcObject MediaSourceHandle: > * w3c/media-source#305 > * further clarifications in discussion at > w3c/media-source#306 (comment) > > BUG=878133 > > Change-Id: I60ddca79ee0f95c87b6d84e4f44ad9c283f359a3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3698231 > Commit-Queue: Matthew Wolenetz <[email protected]> > Auto-Submit: Matthew Wolenetz <[email protected]> > Reviewed-by: Will Cassella <[email protected]> > Cr-Commit-Position: refs/heads/main@{#1012712} Bug: 878133 Change-Id: I1e405ae1de146d1f3183592b00a43bd3c38d849d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3695890 Bot-Commit: Rubber Stamper <[email protected]> Commit-Queue: Nidhi Jaju <[email protected]> Owners-Override: Nidhi Jaju <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012823}

…bjectURL" This reverts commit 6315549b8c2ece3dbbf3062c1a87347589a5e115. Reason for revert: This is causing failures on the WebKit Linux Leak builder i.e. https://ci.chromium.org/ui/p/chromium/builders/ci/WebKit%20Linux%20Leak/39394/overview Original change's description: > MSE-in-Workers: srcObject part 5: Conditionally fail worker objectURL > > If the MediaSourceInWorkersUsingHandle feature is enabled, this change > prevents successful ability of obtaining an objectURL that would succeed > in loading a worker-owned MediaSource. > > It changes the wpt tests to use handle for attachment and verifies > expected new behavior of getHandle and that worker objectURL attachment > fails (these tests run on experimental builds of Chromium with > currently-experimental MediaSourceInWorkersUsingHandle feature enabled, > just like the currently-experimental MediaSourceInWorkers feature.) > > References: > Full prototype CL for the parts 1-4 that have already landed: > https://chromium-review.googlesource.com/c/chromium/src/+/3515334 > MSE spec issue: > w3c/media-source#175 > MSE spec feature updates switching from worker MSE attachment via > object URL to attachment via srcObject MediaSourceHandle: > * w3c/media-source#305 > * further clarifications in discussion at > w3c/media-source#306 (comment) > > BUG=878133 > > Change-Id: I60ddca79ee0f95c87b6d84e4f44ad9c283f359a3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3698231 > Commit-Queue: Matthew Wolenetz <[email protected]> > Auto-Submit: Matthew Wolenetz <[email protected]> > Reviewed-by: Will Cassella <[email protected]> > Cr-Commit-Position: refs/heads/main@{#1012712} Bug: 878133 Change-Id: I1e405ae1de146d1f3183592b00a43bd3c38d849d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3695890 Bot-Commit: Rubber Stamper <[email protected]> Commit-Queue: Nidhi Jaju <[email protected]> Owners-Override: Nidhi Jaju <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012823}

…ionally fail worker objectURL, a=testonly Automatic update from web-platform-tests MSE-in-Workers: srcObject part 5: Conditionally fail worker objectURL If the MediaSourceInWorkersUsingHandle feature is enabled, this change prevents successful ability of obtaining an objectURL that would succeed in loading a worker-owned MediaSource. It changes the wpt tests to use handle for attachment and verifies expected new behavior of getHandle and that worker objectURL attachment fails (these tests run on experimental builds of Chromium with currently-experimental MediaSourceInWorkersUsingHandle feature enabled, just like the currently-experimental MediaSourceInWorkers feature.) References: Full prototype CL for the parts 1-4 that have already landed: https://chromium-review.googlesource.com/c/chromium/src/+/3515334 MSE spec issue: w3c/media-source#175 MSE spec feature updates switching from worker MSE attachment via object URL to attachment via srcObject MediaSourceHandle: * w3c/media-source#305 * further clarifications in discussion at w3c/media-source#306 (comment) BUG=878133 Change-Id: I60ddca79ee0f95c87b6d84e4f44ad9c283f359a3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3698231 Commit-Queue: Matthew Wolenetz <[email protected]> Auto-Submit: Matthew Wolenetz <[email protected]> Reviewed-by: Will Cassella <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012712} -- wpt-commits: 3fec1e386568b78c390acee2307b5a07b75e3d30 wpt-pr: 34364

…: Conditionally fail worker objectURL", a=testonly Automatic update from web-platform-tests Revert "MSE-in-Workers: srcObject part 5: Conditionally fail worker objectURL" This reverts commit 6315549b8c2ece3dbbf3062c1a87347589a5e115. Reason for revert: This is causing failures on the WebKit Linux Leak builder i.e. https://ci.chromium.org/ui/p/chromium/builders/ci/WebKit%20Linux%20Leak/39394/overview Original change's description: > MSE-in-Workers: srcObject part 5: Conditionally fail worker objectURL > > If the MediaSourceInWorkersUsingHandle feature is enabled, this change > prevents successful ability of obtaining an objectURL that would succeed > in loading a worker-owned MediaSource. > > It changes the wpt tests to use handle for attachment and verifies > expected new behavior of getHandle and that worker objectURL attachment > fails (these tests run on experimental builds of Chromium with > currently-experimental MediaSourceInWorkersUsingHandle feature enabled, > just like the currently-experimental MediaSourceInWorkers feature.) > > References: > Full prototype CL for the parts 1-4 that have already landed: > https://chromium-review.googlesource.com/c/chromium/src/+/3515334 > MSE spec issue: > w3c/media-source#175 > MSE spec feature updates switching from worker MSE attachment via > object URL to attachment via srcObject MediaSourceHandle: > * w3c/media-source#305 > * further clarifications in discussion at > w3c/media-source#306 (comment) > > BUG=878133 > > Change-Id: I60ddca79ee0f95c87b6d84e4f44ad9c283f359a3 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3698231 > Commit-Queue: Matthew Wolenetz <[email protected]> > Auto-Submit: Matthew Wolenetz <[email protected]> > Reviewed-by: Will Cassella <[email protected]> > Cr-Commit-Position: refs/heads/main@{#1012712} Bug: 878133 Change-Id: I1e405ae1de146d1f3183592b00a43bd3c38d849d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3695890 Bot-Commit: Rubber Stamper <[email protected]> Commit-Queue: Nidhi Jaju <[email protected]> Owners-Override: Nidhi Jaju <[email protected]> Cr-Commit-Position: refs/heads/main@{#1012823} -- wpt-commits: 9589b7d7210eb65f30af294f454912a5e90a7d53 wpt-pr: 34371

karlt · 2022-06-14T05:24:29Z

As I understand it, all major browser implement the same behavior for message posting, which is broadcasting to all content script realms.

That sounds very inefficient, especially for something large like a VideoFrame, at least unless there's shared memory access involved. But efficiency is much less an issue for transferring MediaSourceHandle.

In WebCodecs we wanted to be able to have move semantics for VideoFrame but this detail made it impossible to implement in practice.

I would guess that ReadableStream.tee() support requires a Serializable object. We don't need that for MediaSourceHandle.

I do want to recommend against inventing a new model for object ownership. If you don't follow the JS-like path (cloneable objects that are GC'd), there are surprising roadblocks.

There is no new object ownership model proposed here.
MediaSourceHandle can be GC'ed without any need to be clonable/Serializable.

While merely transferable and not serializable, MediaSourceHandle cannot be transferred through BroadcastChannel, which is consistent with transfer of MessagePort.

I don't think this is an option. Transferable isn't its own concept (or even an IDL attribute any more), it's a detail of the structured clone algorithm. If you can't serialize it, you can't transfer it either.

Transferable objects already exist without any need to be Serializable: MessagePort, ReadableStream, WritableStream, and TransformStream are all examples of objects that are Transferable, but not Serializable. If browsers can implement these objects, then I don't see any reason why a Transferable and not Serializable MediaSourceHandle would be a problem.

All these objects serve a similar purpose to MediaSourceHandle in that they provide potentially cross-realm communication with at most one associated other object. (tee() is an explicit extension of this involving additional objects.)

VideoFrame is very different. VideoFrames are data, not communication portals (end-points).

A sensible way to implement and even spec MediaSourceHandle would be that it hold a MessagePort created when MediaSource.getHandle() is called, to be used as [[port to worker]] on HTMLMediaElement.

If there is a way to accomplish this combination, note that it would also prevent passing these handles through a TransferableStream.

What do you mean by TransferableStream? If you can edit and link to a spec, that might be helpful, please?

We don't have any need to pass MediaSourceHandles through ReadableStream, etc.
MediaSourceHandles are not "created, processed, and consumed in an incremental fashion", they are not transferred in large numbers, and they do not need backpressure.

@karlt

Work-in-progress update, refactoring previous PR commit to align with results of discussion on that PR. Overall intent for a `MediaSourceHandle` is that it should be [Transferable], and be restricted to "at most one" successful attachment to the underlying `MediaSource` by a handle. Further, if a `Window` `MediaSource` was previously attached using a legacy MSE object URL, subsequent attempts to use that `MediaSource` instance's `MediaSourceHandle` for attachment must also fail. * Changes `MediaSource.getHandle()` to be a `[SameObject] readonly attribute` named `handle`. * Adds HTMLMediaElement.srcObject extension subsection. * Updates MediaSourceHandle transfer and related attachment text to more clearly indicate that transferring a handle prevents re-transfer of that instance due to the [[Detached]] internal slot's logic, and that transfer is also synchronously prevented if the handle instance's [[has ever been assigned as srcobject]] internal slot is true. Also adds multiple notes to describe intent and to clarify. * Updates the "attaching to a media element" text to indicate that a `MediaSourceHandle` can be attached successfully to at most one media element ever. Note that legacy MSE object URL attachments similarly already achieve the same intent in existing implementations. This change includes a clarification for MSE object URL attachments, since it was never the intent even for main-thread `MediaSource` attachments for them to be successfully attached to more than one `HTMLMediaElement` at a time. The switch to more clear `srcObject` usage for worker MSE attachment affords the spec an opportunity to be more clear about this intent. This refinement originates from discussion on the previous PR with @karlt (w3c#305) and from lengthy discussion on this change itself at w3c#306. This work is associated with the MSE-in-Worker spec issue: w3c#175

@karlt

Overall intent for a `MediaSourceHandle` is that it should be [Transferable], and be restricted to "at most one" successful attachment to the underlying `MediaSource` by a handle. Further, if a `Window` `MediaSource` was previously attached using a legacy MSE object URL, subsequent attempts to use that `MediaSource` instance's `MediaSourceHandle` for attachment must also fail. * Changes `MediaSource.getHandle()` to be a `[SameObject] readonly attribute` named `handle`. * Adds HTMLMediaElement.srcObject extension subsection. * Updates MediaSourceHandle transfer and related attachment text to more clearly indicate that transferring a handle prevents re-transfer of that instance due to the [[Detached]] internal slot's logic, and that transfer is also synchronously prevented if the handle instance's [[has ever been assigned as srcobject]] internal slot is true. Also adds multiple notes to describe intent and to clarify. * Updates the "attaching to a media element" text to indicate that a `MediaSourceHandle` can be attached successfully to at most one media element ever. Note that legacy MSE object URL attachments similarly already achieve the same intent in existing implementations. This change includes a clarification for MSE object URL attachments, since it was never the intent even for main-thread `MediaSource` attachments for them to be successfully attached to more than one `HTMLMediaElement` at a time. The switch to more clear `srcObject` usage for worker MSE attachment affords the spec an opportunity to be more clear about this intent. This refinement originates from discussion on the previous PR with @karlt (w3c#305) and from lengthy discussion on this change itself at w3c#306. This work is associated with the MSE-in-Worker spec issue: w3c#175

@karlt

Overall intent for a `MediaSourceHandle` is that it should be [Transferable], and be restricted to "at most one" successful attachment to the underlying `MediaSource` by a handle. Further, if a `Window` `MediaSource` was previously attached using a legacy MSE object URL, subsequent attempts to use that `MediaSource` instance's `MediaSourceHandle` for attachment must also fail. * Changes `MediaSource.getHandle()` to be a `[SameObject] readonly attribute` named `handle`. * Adds HTMLMediaElement.srcObject extension subsection. * Updates MediaSourceHandle transfer and related attachment text to more clearly indicate that transferring a handle prevents re-transfer of that instance due to the [[Detached]] internal slot's logic, and that transfer is also synchronously prevented if the handle instance's [[has ever been assigned as srcobject]] internal slot is true. Also adds multiple notes to describe intent and to clarify. * Updates the "attaching to a media element" text to indicate that a `MediaSourceHandle` can be attached successfully to at most one media element ever. Note that legacy MSE object URL attachments similarly already achieve the same intent in existing implementations. This change includes a clarification for MSE object URL attachments, since it was never the intent even for main-thread `MediaSource` attachments for them to be successfully attached to more than one `HTMLMediaElement` at a time. The switch to more clear `srcObject` usage for worker MSE attachment affords the spec an opportunity to be more clear about this intent. This refinement originates from discussion on the previous PR with @karlt (w3c#305) and from lengthy discussion on this change itself at w3c#306. This work is associated with the MSE-in-Worker spec issue: w3c#175

wolenetz · 2022-07-19T22:32:24Z

@mwatson2 @karlt @jernoble (and @jan-ivar)
Please take a look at this updated PR. I've made significant changes to the original refinement PR, per our conversations. Experimental implementation of this is in Chromium M105 (as of 105.0.5180.0), and associated web-platform-tests have been added/updated.

Thank you all for your input!

edited to add Chromium version detail.

…mpler [SameObject] handle attr, a=testonly Automatic update from web-platform-tests MSE-in-Workers: Switch getHandle() to simpler [SameObject] handle attr Following discussion in the spec PR #306 [1], this change updates the way to obtain a MediaSourceHandle to be via a "handle" attribute on the MediaSource instance that is both readonly and always returns the same object (or throws exception, if for instance, it is attempted to be read from a main-thread-owned MediaSource instance instead of a dedicated- worker-owned MediaSource instance). Also included is the removal of the readyState check when attempting to obtain this handle (since it is now never expected to be changeable; no sequence of distinct handles is ever expected to be obtainable from a worker MediaSource). Also removed is the prevention of retrieving such a handle from an instance more than once. Multiple tests are added or updated to ensure correct behavior. [1] w3c/media-source#306 BUG=878133 Change-Id: Ic07095d6d1dc95b8e6be818027984600aa7ab334 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3750140 Commit-Queue: Matthew Wolenetz <[email protected]> Reviewed-by: Will Cassella <[email protected]> Cr-Commit-Position: refs/heads/main@{#1024034} -- wpt-commits: 5d309d6f31a279218ff15302e8cfa22c95028267 wpt-pr: 34827

wolenetz · 2022-07-22T18:16:10Z

@mwatson2 please take a look.
@karlt @jan-ivar @jernoble please also take a look.

I'd like to merge this ASAP as I believe it addresses the concerns and the use case. Hopefully any further feedback is editorial in nature and could be addressed in later PRs.

media-source-respec.html

karlt

Thank you for taking onboard our suggestions. I like this design.

media-source-respec.html

Editorial only, based on PR comment: w3c#306 (comment)

Mostly editorial, in response to PR review comments. Non-editorial change: * Adds condition on [[Detached]] internal slot of a MediaSourceHandle, preventing successful attachment start if the handle instance is already transferred (detached). Editorial changes: * Replaces "been used beyond this point" text with a new MediaSource internal slot [[has ever been attached]]. Adds that slots definition and initialization in the MediaSource section, and also updates that internal slot to be true in the attaching steps. * Removes redundant-with-readyState-closed clause "being using beyond this point".

…orithm text Editorial change in response to PR comment: w3c#306 (comment) Changes "these clarifications" to "these requirements"

…etch algorithm text Editorial change in response to PR comment: w3c#306 (comment) Changes "do not apply" to "shall not apply"

In response to PR comment: w3c#306 (comment)

…ter" Editorial change in response to PR comment: w3c#306 (comment) Adds normative reference to ECMAScript's definition of agent cluster, and adds an informative reference to related concepts in HTML where agent and agent cluster concepts from ECMAScript are integrated into HTML for Web APIs.

…note In response to PR comment: w3c#306 (comment)

Editorial, in response to PR comments: w3c#306 (comment) w3c#306 (comment) StructuredSerializeWithTransfer already moderates transfer success of Transferable objects like MediaSourceHandle with the object's [[Detached]] internal slot, so explicit extra steps to do this just for MediaSourceHandle are unnecessary and potentially confusing. Removed.

wolenetz · 2022-07-26T23:09:18Z

I believe I have addressed all feedback. I'll squash and merge this PR shortly. Please file an issue if you see anything further needing correction once that merge has happened. Thank you, everyone, for your comments.

@wolenetz

SHA: 099830e Reason: push, by @wolenetz Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

…mpler [SameObject] handle attr, a=testonly Automatic update from web-platform-tests MSE-in-Workers: Switch getHandle() to simpler [SameObject] handle attr Following discussion in the spec PR #306 [1], this change updates the way to obtain a MediaSourceHandle to be via a "handle" attribute on the MediaSource instance that is both readonly and always returns the same object (or throws exception, if for instance, it is attempted to be read from a main-thread-owned MediaSource instance instead of a dedicated- worker-owned MediaSource instance). Also included is the removal of the readyState check when attempting to obtain this handle (since it is now never expected to be changeable; no sequence of distinct handles is ever expected to be obtainable from a worker MediaSource). Also removed is the prevention of retrieving such a handle from an instance more than once. Multiple tests are added or updated to ensure correct behavior. [1] w3c/media-source#306 BUG=878133 Change-Id: Ic07095d6d1dc95b8e6be818027984600aa7ab334 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3750140 Commit-Queue: Matthew Wolenetz <[email protected]> Reviewed-by: Will Cassella <[email protected]> Cr-Commit-Position: refs/heads/main@{#1024034} -- wpt-commits: 5d309d6f31a279218ff15302e8cfa22c95028267 wpt-pr: 34827

With [spec PR #306](w3c/media-source#306) merged and with implementation landed corresponding to that spec already landed in Chromium as of 105.0.5180, MSE-in-Workers requires a MediaSourceHandle transferred from a dedicated worker to attach a worker MediaSource to a media element. This change updates the demo to check for the necessary support and, use handle and srcObject for worker mediasource attachment (still leaving legacy MediaSource object URL for main thread mediasource attachments), and updates various instructions and READMEs accordingly.

wolenetz requested a review from mwatson2 March 31, 2022 18:19

karlt reviewed Apr 1, 2022

View reviewed changes

chromium-wpt-export-bot mentioned this pull request Jun 9, 2022

MSE-in-Workers: srcObject part 5: Conditionally fail worker objectURL web-platform-tests/wpt#34364

Merged

chromium-wpt-export-bot mentioned this pull request Jun 10, 2022

Revert "MSE-in-Workers: srcObject part 5: Conditionally fail worker objectURL" web-platform-tests/wpt#34371

Merged

wolenetz force-pushed the refine-srcobject-worker-semantics branch from 5cf43c4 to aab3d07 Compare July 15, 2022 00:18

wolenetz force-pushed the refine-srcobject-worker-semantics branch from aab3d07 to e4c9091 Compare July 19, 2022 22:13

wolenetz force-pushed the refine-srcobject-worker-semantics branch from e4c9091 to cac171a Compare July 19, 2022 22:14

wolenetz force-pushed the refine-srcobject-worker-semantics branch from cac171a to cf17a58 Compare July 19, 2022 22:28

wolenetz requested a review from jernoble July 19, 2022 22:30

mwatson2 approved these changes Jul 22, 2022

View reviewed changes

karlt approved these changes Jul 26, 2022

View reviewed changes

wolenetz added 8 commits July 26, 2022 13:05

MSE-in-Workers: Update attaching to a media element language

d60266d

Editorial only, based on PR comment: w3c#306 (comment)

MSE-in-Workers: Minor editorial update to extended resource fetch alg…

8ffdbb2

…orithm text Editorial change in response to PR comment: w3c#306 (comment) Changes "these clarifications" to "these requirements"

MSE-in-Workers: Another minor editorial update to extended resource f…

16d5b78

…etch algorithm text Editorial change in response to PR comment: w3c#306 (comment) Changes "do not apply" to "shall not apply"

MSE-in-Workers: Minor editorial clarification to meaning of Detached

f247a63

In response to PR comment: w3c#306 (comment)

MSE-in-Workers: Remove justification from srcObject setter extension …

c62ebd6

…note In response to PR comment: w3c#306 (comment)

wolenetz merged commit 099830e into w3c:main Jul 26, 2022

github-actions bot added a commit that referenced this pull request Jul 26, 2022

Refine srcObject's MediaSourceHandle behavior (#306)

b182b84

SHA: 099830e Reason: push, by @wolenetz Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

wolenetz deleted the refine-srcobject-worker-semantics branch July 26, 2022 23:18

wolenetz mentioned this pull request Jul 27, 2022

MSE in Workers mozilla/standards-positions#547

Open

chromium-wpt-export-bot mentioned this pull request Sep 27, 2022

MSE-in-Workers: Relaunch with flag guards and handle visibility restricted web-platform-tests/wpt#36117

Merged

wolenetz mentioned this pull request Oct 3, 2022

Request for design principle clarification: Warn explicitly against getters throwing exceptions w3ctag/design-principles#400

Closed

Conversation

wolenetz commented Mar 31, 2022 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wolenetz commented Mar 31, 2022

Uh oh!

karlt left a comment

Choose a reason for hiding this comment

Uh oh!

karlt Mar 31, 2022

Choose a reason for hiding this comment

Uh oh!

wolenetz Apr 7, 2022

Choose a reason for hiding this comment

Uh oh!

karlt Apr 11, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wolenetz May 10, 2022

Choose a reason for hiding this comment

Uh oh!

karlt May 10, 2022

Choose a reason for hiding this comment

Uh oh!

wolenetz May 10, 2022

Choose a reason for hiding this comment

Uh oh!

karlt May 10, 2022

Choose a reason for hiding this comment

Uh oh!

karlt Mar 31, 2022

Choose a reason for hiding this comment

Uh oh!

wolenetz commented Jun 1, 2022

Uh oh!

wolenetz commented Jun 1, 2022

Uh oh!

karlt commented Jun 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wolenetz commented Jun 1, 2022

Uh oh!

wolenetz commented Jun 1, 2022

Uh oh!

wolenetz commented Jun 1, 2022

Uh oh!

wolenetz commented Jun 1, 2022

Uh oh!

wolenetz commented Jun 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

karlt commented Jun 3, 2022

Uh oh!

sandersdan commented Jun 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wolenetz commented Jun 3, 2022

Uh oh!

karlt commented Jun 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wolenetz commented Jul 19, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wolenetz commented Jul 22, 2022

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

karlt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wolenetz commented Mar 31, 2022 •

edited by pr-preview bot

Loading

karlt Apr 11, 2022 •

edited

Loading

karlt commented Jun 1, 2022 •

edited

Loading

wolenetz commented Jun 2, 2022 •

edited

Loading

sandersdan commented Jun 3, 2022 •

edited

Loading

karlt commented Jun 14, 2022 •

edited

Loading

wolenetz commented Jul 19, 2022 •

edited

Loading