Repository navigation
Media element resource selection algorithm: resolve the URL lazily, matching implementations #798
Description
https://html.spec.whatwg.org/multipage/embedded-content.html#concept-media-load-algorithm
The problem exists in two places:
"Let urlString be the resulting URL string that would have resulted from parsing the URL specified by the src attribute's value relative to the media element's node document when the src attribute was last changed."
"Let urlString be the resulting URL string that would have resulted from parsing the URL specified by candidate's src attribute's value relative to the candidate's node document when the src attribute was last changed."
I never implemented this in Presto, and it's not what happens in WebKit or Blink either. Instead the URL is just resolved right then and there. There's a difference when the document's base URL changes in between the two times, but it doesn't seem to matter in practice.
@padenot, what does Gecko do?
@DigiTec, who's a good contact for media element issues in Edge?
Activity
padenot commentedon Mar 4, 2016
Yeah I think that's what Gecko does. When loading, it simply looks at the URL and loads this media. It's unclear what the purpose of current prose is, though.
zcorpan commentedon Mar 4, 2016
I think the purpose is indeed to have non-racy behavior with base URL changes.
foolip commentedon Mar 11, 2016
There's another similar case for
<track>:Blink doesn't do this either. Searching for some of strings used in these contexts, I can't find any other place in HTML that does this. @zcorpan, can you confirm that
<picture>doesn't do anything like this?It seems like the behavior would be well defined without these bits, it's just that it could be surprising if one changes the base URL at an inopportune moment.
zcorpan commentedon Mar 11, 2016
https://html.spec.whatwg.org/multipage/embedded-content.html#update-the-image-data
https://html.spec.whatwg.org/multipage/embedded-content.html#img-environment-changes
imgparses the URL right before fetching.I looked through all instances of "parse a URL" in the spec and almost everything parses the URL lazily, not eagerly. So it makes sense to me to switch
videoandtrackto be consistent with the rest of the spec (and what implementations do).The only possible exception (other than
videoandtrack) is thebackgroundattributehttps://html.spec.whatwg.org/#the-page:parse-a-url
https://html.spec.whatwg.org/#tables-2:parse-a-url
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3985
WebKit/Blink seem to parse the URL after the base URL change; Gecko seems to parse the URL before (i.e. like the spec). To get racy behavior here it seems we could just not parse the URL but pass along the unparsed value to the style layer.
(http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3986 shows that base URL changes don't cause the
backgroundattribute to be re-evaluated; same with URLs in author-level CSS.)annevk commentedon Mar 11, 2016
I think we need to parse eagerly actually. Otherwise
blobURLs would be non-deterministic.zcorpan commentedon Mar 11, 2016
Hmm right, I had forgotten about
blobURLs. In that case I suppose we should parse URLs eagerly everywhere?annevk commentedon Mar 11, 2016
Ideally, if we ever hope to make the deterministic.
foolip commentedon Mar 11, 2016
Is this really about non-determinism? The exact time at which the URL is resolves is well defined in any case, and whatever the window of time is where a
blobURL is unreliable, it should be possible to hit that window with both eager and lazy URL resolving.annevk commentedon Mar 11, 2016
I think ideally when you assign a
blobURL it's associated object is cloned directly. Otherwise you can assign it somewhere else, and then it's a matter of knowing which one does something first. I think that's non-determinism.foolip commentedon Mar 11, 2016
Maybe hard to understand, but still deterministic as long as the spec defines when the URLs are resolved, right? Resolving eagerly everywhere sounds like quite a hassle, resolved URLs would need to be stored all over the place just in cast they're later needed.
annevk commentedon Mar 12, 2016
It's not deterministic if it can take some arbitrary amount of time, which I think is the alternative, if you leave this up to the networking layer or some such.
foolip commentedon Mar 12, 2016
One has to resolve before starting the fetch, so I'm not sure how to spec eager (or lazy) URL resolving in a way that would have this problem. But I'll try to PR this (eventually) and we can see if there are in fact race conditions before or after the change.