Closed Bug 1752132 Opened 6 months ago Closed 4 months ago

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

Categories

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

Firefox 98
Desktop
All
defect
Points:
3

Tracking

()

VERIFIED FIXED
100 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- verified
firefox101 --- verified

People

(Reporter: mtigley, Assigned: niklas)

References

Details

(Whiteboard: [fidefe-MR1-2022])

Attachments

(1 file)

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.

Severity: -- → S2
Priority: -- → P1

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.

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.

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.

Priority: P1 → P2

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.

Severity: S2 → S3
Depends on: 1753281

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.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1614982
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → RESOLVED
Closed: 6 months ago6 months ago
Priority: P2 → P3
Resolution: --- → DUPLICATE
Duplicate of bug: 1614982
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Duplicate of this bug: 1614982
Whiteboard: [fidefe-MR1-2022]
Assignee: nobody → nbaumgardner
Status: REOPENED → ASSIGNED
Points: --- → 3
Pushed by nbaumgardner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9e8c65257d06
Netflix site specific adapter for play/pause. r=mhowell,kpatenio
Status: ASSIGNED → RESOLVED
Closed: 6 months ago5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

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

Status: RESOLVED → VERIFIED

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.

Status: VERIFIED → REOPENED
OS: Unspecified → All
Hardware: Unspecified → Desktop
Resolution: FIXED → ---

(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.

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.

Flags: needinfo?(nbaumgardner)

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

Status: REOPENED → RESOLVED
Closed: 5 months ago4 months ago
Resolution: --- → FIXED

This will be fixed with bug 1763190

Flags: needinfo?(nbaumgardner)

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.

Status: RESOLVED → VERIFIED

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

You need to log in before you can comment on or make changes to this bug.