2029014 - VTT resources for a video element don't get loaded (after one has previously loaded)

Status: NEW

(Core :: Audio/Video, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: (vtt file to be used in testcase)

STR:

1. Load attached testcase.
2. Click the button.
3. Click the button again (as many times as you like)

EXPECTED RESULTS:
Each button press should result in logging like so (where N is an incrementing counter):

Appended track #N
Load event fired for track #N

ACTUAL RESULTS:
The "Load event fired" logging never appears for any button press after the first one.

This seems to be the underlying platform bug behind WebCompat Site Report bug 2028931.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Very quick diagnosis from poking in GDB...

It looked to me like each track element has a Mode() of TextTrackMode::Disabled by default -- and when a track has that Disabled mode, it bails from MaybeDispatchLoadResource() without actually dispatching any task to load the resource, here:
https://searchfox.org/firefox-main/rev/98bf4b92d3f5d7a9855281df4bf333210bcfbbc4/dom/media/webvtt/HTMLTrackElement.cpp#249,252-253,255-257

void HTMLTrackElement::MaybeDispatchLoadResource() {
...
  // step2, if the text track's text track mode is not set to one of hidden or
  // showing, then return.
...
  if (mTrack->Mode() == TextTrackMode::Disabled && !resistFingerprinting) {
    LOG("Do not load resource for disable track");
    return;

The very first track manages to avoid that problem, because we get a call to HonorUserPreferencesForTrackSelection which changes the mode of all disabled tracks here:
https://searchfox.org/firefox-main/rev/98bf4b92d3f5d7a9855281df4bf333210bcfbbc4/dom/media/webvtt/TextTrackManager.cpp#328-331,341-352

void TextTrackManager::HonorUserPreferencesForTrackSelection() {
  if (performedTrackSelection || !mTextTracks) {
    return;
  }
...
  // Step 4: Set all TextTracks with a kind of metadata that are disabled
  // to hidden.
  for (uint32_t i = 0; i < mTextTracks->Length(); i++) {
    RefPtr<TextTrack> track = (*mTextTracks)[i];
    if (track->Kind() == TextTrackKind::Metadata && TrackIsDefault(track) &&
        track->Mode() == TextTrackMode::Disabled) {
      track->SetMode(TextTrackMode::Hidden);
    }
  }

  performedTrackSelection = true;
}

I think later tracks trigger that same call to HonorUserPreferencesForTrackSelection, but they skip the important parts of that function because performedTrackSelection is now true which makes them take the early-return at the start of the function.

Comment 3

[Daniel Holbert [:dholbert]]

This is a regression, with this regression range:
Last good revision: 5d3e1ea7769357bce7297b83be3863034bcf656e (2019-05-24)
First bad revision: edbf8267dd4f5a786ae660ff9e2fe890cf74c48e (2019-05-25)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5d3e1ea7769357bce7297b83be3863034bcf656e&tochange=edbf8267dd4f5a786ae660ff9e2fe890cf74c48e

Looks like a regression from bug 1550633.

alwu, maybe you could take a look?

Comment 4

[Daniel Holbert [:dholbert]]

This isn't the right fix, but FWIW -- if I remove this line (the performedTrackSelection = true; line that I quoted in comment 2), in a local build, then this bug and bug 2028931 both give EXPECTED RESULTS.

Comment 5

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1550633