1363234 - Video keeps playing after navigating back on new polymer youtube.com

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Adam Stevenson [:adamopenweb]]

Attachment: video.png

Tested in Firefox 53 & 55 using OSX 10.12.4

STR:

1. Navigate to https://www.youtube.com/new
2. Click the blue "Try it now" button
3. Select any Youtube video on the home page
4. Let the video start
5. Navigate back to the youtube home page

Expected:
Video and audio stop playing

Actual:
Audio continues to play in background

Harald pointed out that in Chrome the video source is cleared, but not in Firefox.

Comment 1

[Mike Taylor [:miketaylr]]

(taking a wild guess at the right component)

Harald, did you track down the part of Youtube that's clearing <video>.src?

Comment 2

[:Harald Kirschner :digitarald]

I did not try to find the offending code. I got so far to see that in Chrome the video element had `src` removed when navigating back while `src` was still set in Firefox.

Comment 3

[Alice0775 White]

FYI, I can also reproduce the problem on Edge....

Comment 4

[Mike Taylor [:miketaylr]]

The relevant method in base.js seems to be this:

tL = function(a) {
  a.pd() && (sL && 0 < a.getCurrentTime() && mL(a, 0),
  a.g.removeAttribute("src"),
  a.load(),
  jL(a, null))
}

a.g is a reference to the <video> element, and it has a blob src that will look something like:

blob:https://www.youtube.com/360c35ca-82cd-4f72-bc85-329cf59d953d

a.load comes from a prototype method:

g.h.load = function() {
  var a = this.g.playbackRate;
  this.g.load();
  this.g.playbackRate = a
}

So, src is being removed, a reference to the playbackRate prop is stored, load() is called on the video element (which has no src), and playbackRate is set back.

insde of jL(), the following happens:

OI.prototype.dispose = function() {
  if (!this.A) {
    if (this.o)
      try {
        window.URL.revokeObjectURL(this.g)
      } catch (a) {}
        this.A = !0
      }
    }
...

I'd like to try to come up with a reduced testcase, if possible.

Comment 5

[Thomas Wisniewski]

To me this looks like it’s just a logic bug they haven’t fully tested and fixed yet. They intercept the history-back event and turn it into a custom event, yt-history-load, which has a historyEntry property. That in turn has a rootData.player sub-property, which appears to be a reference to the HTML5 player UI for re-use (including the DOM id of the video element). The key difference between Firefox and Chrome is that rootData.player=undefined in Chrome, but it’s an actual value in Firefox.

This should be fine, but the event handler for the yt-history-load event (_loadPageRequest()), only calls _stopPlayer if the player property *isn’t* set (in which case it calls _stopPlayer, which eventually removes the video element’s src attribute). If the player property *is* set however, then it does a bunch of other things, but it never removes the src attribute or pauses the video element. And so, despite it being display:none’d, the video keeps playing and we keep hearing audio.

I’ve confirmed that simply pausing the video element in the code-branch that Firefox takes does the trick, so that’s probably all that it is:

  loadPageRequest_: function(a) {
    var b = null;
    if (a.player) {
      // adding this line seems to do the trick:
      var _c=document.getElementById(a.player.attrs.id);_c && _c.querySelector("video").pause();

Comment 6

[Mike Taylor [:miketaylr]]

Thanks Tom!

I'm gonna email YT on our partner ML (pre-emptively setting to sitewait) and ask if they know why rootData.player has a value in Firefox (and not Chrome).

Comment 13

[Adam Stevenson [:adamopenweb]]

This has been fixed by Google. I can no longer reproduce in Firefox 57 for OSX.