Exposing createObjectURL(mediaSource) in workers seems odd

[foolip]

Since there can be no MediaSource instance in a worker, why have the overload there? Is it that WebIDL requires overloads to all have the same exposure set?

@inexorabletash

[paulbrucecotton]

@foolip: Can you give us an exact reference to the material in the MSE spec that this issue is about?

@wolenetz: Is this related to the solution we applied to ISSUE-67?

[foolip]

It's https://w3c.github.io/media-source/#url and the [Exposed=Window, DedicatedWorker, SharedWorker] in the IDL. This matches https://w3c.github.io/FileAPI/#creating-revoking but is it intentional or just copy-pasted? In https://heycam.github.io/webidl/#Exposed I see nothing about the exposure set of a partial interface having to match the exposure set of the interface itself.

Ping @inexorabletash.

[inexorabletash]

I probably provided bad guidance here. IIRC it was [Exposed=(Window,Worker)] and we wanted to ensure that none of the Blob-URL-minting functions were exposed to Service Workers. I probably suggested that this be scoped to specific workers (minimal change) rather than just window (correct change) due to not thinking about the feature itself.

[foolip]

Cool, so the fix here is to just make it [Exposed=Window]. Thanks @inexorabletash!

[wolenetz]

To be clear, if we continued to (probably mistakenly) allow createObjectURL within a DedicatedWorker or a SharedWorker, in what context might such a URL even be assignable to an HTMLMediaElement's src attribute? Are there similar exposure restrictions on any of HTMLMediaElement operation?

[foolip]

It's actually harmless since there's no way to get a MediaSource instance in a worker, and thus no way to generate such a URL. So consider this editorial.

[wolenetz]

SGTM. I'll prepare a pull request shortly, though I'll need @plehegar to help determine how exactly such a change might make it (is it a post-REC erratum, or something to include for REC; and either way, should this be on mainline gh-pages here?)

@plehegar, a second question: we currently have a registries-publication branch that is a few commits ahead of gh-pages, should we just fast-forward gh-pages to that, or is that branch intentional since it's expected that registry changes can occur without impacting main v1 spec in future?

[wolenetz]

@jdsmith3000 @paulbrucecotton @mwatson2 Also, pending @plehegar's response to my questions, above, triaging this bug to a particular Milestone is TBD.