Exposing createObjectURL(mediaSource) in workers seems odd #168

Closed
foolip opened this Issue Sep 29, 2016 · 10 comments

Projects

None yet

5 participants

@foolip
Member
foolip commented Sep 29, 2016

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

@foolip foolip changed the title from Exposing createObjectURL(mediaSource) seem odd to Exposing createObjectURL(mediaSource) in workers seems odd Sep 29, 2016
@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
Member
foolip commented Nov 7, 2016

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
Member

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
Member
foolip commented Nov 7, 2016

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

@wolenetz
Collaborator
wolenetz commented Nov 7, 2016

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?

@plehegar plehegar modified the milestone: VNext Nov 7, 2016
@foolip
Member
foolip commented Nov 8, 2016

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
Collaborator
wolenetz commented Nov 8, 2016

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 wolenetz self-assigned this Nov 8, 2016
@wolenetz
Collaborator
wolenetz commented Nov 8, 2016

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

@plehegar
Member
plehegar commented Nov 9, 2016

My understanding is that the change is editorial, so I'd expect to include the change as part of the Proposed Recommendation.

@plehegar
Member
plehegar commented Nov 9, 2016

re registries, I created the branch for pull request purpose. I'm fine with synchronizing and remove the branch.

@plehegar plehegar pushed a commit that closed this issue Nov 15, 2016
@wolenetz wolenetz Fix #168 - Restrict createObjectURL(MediaSource) further
Removes SharedWorker and DedicatedWorker exposure for this method,
leaving exposure only on Window.
Also includes updates to previousMaturity and previousPublishDate.
9bb87ae
@plehegar plehegar closed this in 9bb87ae Nov 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment