1681718 - Play/Pause button in PiP window and media controls do not work on twitch while the Firefox window is minimized

Status: RESOLVED WORKSFORME

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

Description

[Alin Ilea, Desktop Test Engineering]

Tested with:

Nightly 85.0a1 (2020-12-10)
Beta 84
Release 83.0

Tested on:

Windows 10
Windows 7
MacOS Big Sur 11

Steps:

1. Launch firefox and access: https://www.twitch.tv/
2. Choose any video/stream and toggle the PiP window
3. Minimize the Firefox window
4. Click pause/play in the PiP window

Actual result:

The play button from the PiP window doesn't work anymore after the user clicks the pause button, while the Firefox window is minimized.

Expected result:

Play PiP window button should work properly and the user should be able to play/pause the video in PiP window.

Regression range:

Will look for the regression range asap.

Severity suggestion: S3

Comment 1

[:Gijs (he/him)]

I wonder if this is twitch-specific. I can repro with twitch, but not on youtube. However, I see the same thing with media controls - pausing works but playing doesn't work when the page is minimized.

Alastor, do you know what might cause that?

Comment 2

[Alastor Wu [:alwu]]

When I see this issue, here is the log I capture.

[Child 1187981: Main Thread]: D/nsMediaElement 0x7fa4e2913800 Play() called by JS readyState=1
[Child 1187981: Main Thread]: D/nsMediaElement 0x7fa4e2913800 created PlayPromise 0x7fa339eafec0
[Child 1187981: Main Thread]: D/nsMediaElement MediaElement 0x7fa4e2913800 UpdateReadyStateInternal() NEXT_FRAME_UNAVAILABLE_SEEKING; Forcing HAVE_METADATA
[Child 1187981: Main Thread]: D/nsMediaElement 0x7fa4e2913800 Pause() called by JS
[Child 1187981: Main Thread]: D/nsMediaElement MediaElement 0x7fa4e2913800 UpdateReadyStateInternal() NEXT_FRAME_UNAVAILABLE_SEEKING; Forcing HAVE_METADATA
[Child 1187981: Main Thread]: D/nsMediaElement PlayPromise 0x7fa339eafec0 rejected with 0x806e0001 (PauseAbortErr)
JavaScript error: , line 0: AbortError: The fetching process for the media resource was aborted by the user agent at the user's request.

After we call play via play button on PIP window, website's script calls pause following by. I think that is related with the visibility issue, because in current spec, when using video in PIP window, the page visibility would be invisible so website can't distinguish between "playing a background invisible video" and "playing a visible video via PIP window". So this issue seems to me that Twitch explicity pauses the video because they think video is invisible to users.

We've encoutered similar issues where website would lower its video resolution after playing video in PIP window for a while. Before we tackle PIP window as a factor into the spec of document visibility, maybe the patch in bug1598654 can help this.

Comment 3

[Alastor Wu [:alwu]]

I'm not sure what we can do here, because I think the issue is caused by website pausing media due to the hidden page.

---

Hi, Mike, Do you have any idea about this issue? Will your patch in bug1598654 help in this one?
Thank you.

Comment 4

[:Gijs (he/him)]

(In reply to Alastor Wu [:alwu] from comment #3)

I'm not sure what we can do here, because I think the issue is caused by website pausing media due to the hidden page.

Right, I think one fix would be to not mark the page hidden if there's a pip window open... but I don't know how straightforward that'd be.

Comment 5

[Alastor Wu [:alwu]]

(In reply to :Gijs (he/him) from comment #4)

Right, I think one fix would be to not mark the page hidden if there's a pip window open... but I don't know how straightforward that'd be.

There are some discussions in bug1598654 (comment5~7) where DOM team has some concerns about simply marking page as visible.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Sorry for the looooong delay. Yes, it's possible that bug 1598654 would help with this - although the patch in there never landed.

Comment 7

[kpatenio]

As a result of Bug 1755748 having landed (which happens to fix Bug 1598654), I can't reproduce this bug on MacOS.

Comment 8

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

I can't reproduce this on Windows 11 either. I think we can call it here.