Exposing createObjectURL(mediaSource) in workers seems odd #168
|
It's https://w3c.github.io/media-source/#url and the Ping @inexorabletash. |
|
I probably provided bad guidance here. IIRC it was |
|
Cool, so the fix here is to just make it |
|
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? |
|
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. |
|
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? |
|
@jdsmith3000 @paulbrucecotton @mwatson2 Also, pending @plehegar's response to my questions, above, triaging this bug to a particular Milestone is TBD. |
|
My understanding is that the change is editorial, so I'd expect to include the change as part of the Proposed Recommendation. |
|
re registries, I created the branch for pull request purpose. I'm fine with synchronizing and remove the branch. |
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