1787632 - Possible interop issues with order in which video events fire versus setTimeout(0) callbacks

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Thomas Wisniewski [:twisniewski]]

Videos on worldviewweekend.com, such as this one, end up not hiding their "no sources found" VideoJS banner in Firefox, while they do in Chrome.

This is partly site error, because they they have four scripts playing VideoJs on the same element, but only the first sets a valid source (the other three are blank). So as the scripts run in order (not async), it makes logical sense that the banner would be shown, since it appears on an error. But it's all down to script timing.

The version of VideoJS they're using will use setTimeout(fn, 0) to defer the error banner's display upon setting the source of the video:

    e.src = function (e) {
      var n = // omitting code that "parses out" the source(s) into an array
      n.length ? // omitting code for the "good" case (first of four src-sets in this case)
                     : // else, runs this if no sources found (three times after in this case)
            this.setTimeout(function () {
              this.error(/* not supported message */);
           }, 0)

However, on loadstart for the successful video, they will hide any errors:

    e.handleTechLoadStart_ = function () { // a bare loadStart handler, no setTimeouts involved
      this.removeClass('vjs-ended'),
      this.removeClass('vjs-seeking'),
      this.error(null), // hides any error banners
     // etc

Chrome seems to run the setTimeout callbacks for the three errors before firing the loadStart event on the good video src. Firefox runs the setTimeouts first, then the loadStart event, so the error banner will appear despite the video paradoxically playing fine underneath it.

I'm not sure if this is a spec issue, or if there might be some other reason for the event to fire in a different order compared to the setTimeouts, but since this might be a webcompat issue, I would like to find out. JHLin, maybe you can help?

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Per spec timers use their own queue so there is no guarantee in order of timeouts and other queued tasks.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

This could be actually DOM: Core (since setTimeout is handled there) too ... though, this is really a site issue.
Chrome itself is just tweaking the order by change clamping limits etc.

Comment 3

[Thomas Wisniewski [:twisniewski]]

Hmm. Then I suppose for now the only thing we can do is reach out to the website and maybe try an intervention, and hope we don't find worse issues related to this ordering ambiguity.