Media element resource selection algorithm: resolve the URL lazily, matching implementations

[foolip]

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?

[padenot]

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]

I think the purpose is indeed to have non-racy behavior with base URL changes.

[foolip]

There's another similar case for <track>:

If the element has a src attribute whose value is not the empty string and whose value, when the attribute was set, could be successfully parsed relative to the element's node document, then the element's track URL is the resulting URL string. Otherwise, the element's track URL is the empty string.

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]

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

img parses 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 video and track to be consistent with the rest of the spec (and what implementations do).

The only possible exception (other than video and track) is the background attribute

https://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 background attribute to be re-evaluated; same with URLs in author-level CSS.)

[annevk]

I think we need to parse eagerly actually. Otherwise blob URLs would be non-deterministic.

[zcorpan]

Hmm right, I had forgotten about blob URLs. In that case I suppose we should parse URLs eagerly everywhere?

[annevk]

Ideally, if we ever hope to make the deterministic.

[foolip]

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 blob URL is unreliable, it should be possible to hit that window with both eager and lazy URL resolving.

[annevk]

I think ideally when you assign a blob URL 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]

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]

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]

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.