1752132 - Play button on Netflix video player doesn't work after closing PiP

Status: VERIFIED FIXED

(Toolkit :: Picture-in-Picture, defect, P3)

Description

[Micah [:mtigley] (she/her)]

STR

1. Go to Netflix and navigate to a video.
2. Play the video
3. Open the PiP window
4. Close the PiP window using its "close" button
5. The original video should pause now. Try resuming it by clicking the "play" button on the Netflix player.

Expected
The video should resume playing

Actual
The video remains paused

Some notes: I've tested this in Nightly, but I can also see this issue on latest Firefox release.

Comment 1

[Ania]

Micah, thank you for catching this.
I just reproduced it in 96.0.3 - let's see if we can try to squeeze it into the upcoming Nightly.

Comment 2

[Molly Howell (she/her) (mostly inactive)]

A few relevant facts that I've noticed right off the bat:

1. This doesn't happen if you use the unpip button instead of the close button. The relevant difference between those things appears to be that the unpip button does not attempt to pause the video in the first place, but I still think it's notable that no problems happen with pausing/playing the video after that point.
2. You can also get the same bug to happen by using the PIP window's pause button and then trying to use the site's play button. It will fail to work in exactly the same way.
3. I can consistently get out of this bad state by manually calling play() on the video element from the console.

To me, this seems to point to something being wrong with how PIP implements pausing, because it appears to be the pause operation that breaks things, not anything else to do with closing the PIP window. The only problem with that theory is that the way PIP implements pausing is... by calling pause() on the video element. There's no complex logic or strange hacking going on in there, it's just doing the simplest, most standard thing possible, and there's no reason to expect that it shouldn't work. Which means that Netflix is expecting something more than just the standard thing; my guess is that there's a separate copy somewhere of the play/pause state, and the player is relying on that instead of the state of the video element. If that's true, then the fix would be to add management of that state to a Netflix site-specific adapter (a thing which, to be clear, does not yet exist as of this writing), assuming we can actually identify where that state is, which I've not yet managed to do.

Comment 3

[Ania]

Thank you so much for doing the initial reconnaissance, Molly.

I have dropped priority to P2, and since it looks like an investigative piece, do you think it's worth/there's the potential capacity to look into it within Fx 100? Or, given all the work we've committed for 100, the best we can shoot for to start looking into this is 101?

There's no indication so far that a lot of users are impacted by this use case, and point #1 is a very partial workaround we can point users to in the meantime.

Comment 4

[Micah [:mtigley] (she/her)]

In reply to Molly Howell (she/her) [:mhowell] from comment #2)

Which means that Netflix is expecting something more than just the standard thing; my guess is that there's a separate copy somewhere of the play/pause state, and the player is relying on that instead of the state of the video element. If that's true, then the fix would be to add management of that state to a Netflix site-specific adapter (a thing which, to be clear, does not yet exist as of this writing), assuming we can actually identify where that state is, which I've not yet managed to do.

Perhaps this play/pause state is accessible on their player api? I believe mconley played around with implementing a video wrapper script that attempts to use it. Unfortunately, official documentation on this is, at best, very sparse and will likely require some poking around.

Comment 5

[Ania]

I realized that this must be a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1614982, and Alastor Wu has contacted Netflix about the issue in November 2021 - https://groups.google.com/a/mozilla.com/g/mozilla-netflix-discuss/c/0K0NbPGDIbw

I'm going to follow up with them via the Google Groups.

Comment 8

[Niklas Baumgardner [:niklas]]

Attachment: Bug 1752132 - Netflix site specific adapter for play/pause. r=mhowell!,kpatenio!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9e8c65257d06
Netflix site specific adapter for play/pause. r=mhowell,kpatenio

Comment 10

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9e8c65257d06

Comment 11

[Daniel Bodea [:danibodea]]

This fix is verified in Nightly v100.0a1 from 2022-03-15 on Windows 10, Mac OS 11 and Ubuntu 20/22.

Comment 12

[Daniel Bodea [:danibodea]]

This issue seems to still affect the beta channel (Beta v100.0b1), while the nightly channel still seems fixed (Nightly v101.0a1).
This bug also appeared with this first beta build: bug 1763190. Maybe they are related.

Comment 13

[kpatenio]

(In reply to Bodea Daniel [:danibodea] from comment #12)

This issue seems to still affect the beta channel (Beta v100.0b1), while the nightly channel still seems fixed (Nightly v101.0a1).
This bug also appeared with this first beta build: bug 1763190. Maybe they are related.

I believe they are. Left a comment in bug 1763190 about why this may be happening.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:niklas, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 15

[Mathew Hodson]

Wrapper scripts were enabled on Nightly only. Bug 1763190 removed the NIGHTLY_BUILD check.

Comment 16

[Niklas Baumgardner [:niklas]]

This will be fixed with bug 1763190

Comment 17

[Daniel Bodea [:danibodea]]

I have verified this fix on Beta v100.0b5 on Windows 10, Mac OS 11 and Ubuntu 20. Netflix no longer shows the issue described in comment 0.

Comment 18

[Daniel Bodea [:danibodea]]

It appears some flags were incorrectly modified. This issue still occurs on branch 97 and down (ESR91).