1611643 - Autoplayed next video should also be PIP

Status: ASSIGNED

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

Description

[Asif Youssuff]

Seen this asked for on various places, but also experienced a desire for this myself.

1. Start watching a series on Plex or Netflix
2. Enter PIP
3. Navigate to another app (like a game)

Once the next video starts playing (initiated by the website), PIP mode is disabled and the video continues playing in the original window. User has to move back to the Firefox tab and re-enable PIP.

It'd be nice if PIP were to recognize that a video started to play in the same tab that the original PIP video was being played from, and showed the new video in PIP as well.

Comment 1

[alex_mayorga]

¡Hola!

Just experienced this in Nightly and it is in fact a bit jarring.

Updating flags accordingly FWIW.

¡Gracias!
Alex

Comment 3

[OpenMySourceCode]

Udemy.com is also affected by this bug when viewing course videos.

Comment 4

[OpenMySourceCode]

By the way, is there a way to bump this? Because it's interfering with my workflow and I can't be the only one.

Comment 5

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

One idea to address this is to notice when PiP is shut down due to <video> element removal, and to remember the coordinates of the removed <video>... and then have a timer that checks to see if a new <video> element exists at (roughly) the same coordinates, and if so, open that in PiP. That timer would probably need to be on the scale of seconds - say 1 or 2 to start.

This timer should be tied to the lifetime of the document, so if the page navigates away somehow, we should cancel the timer and throw it away.

Comment 6

[Swapnik Katkoori]

Attachment: WIP: Bug 1611643 - Allow PiP to autoplay on Plex. r=mtigley!,mhowell!

Comment 7

[kpatenio]

Attachment: WIP: Bug 1611643 - added test case for running autoplayed videos on PiP. r=mtigley!,mhowell!

Comment 8

[OpenMySourceCode]

So wait. Does this mean the fix is in the next version of Firefox?

Comment 9

[kpatenio]

(In reply to OpenMySourceCode from comment #8)

So wait. Does this mean the fix is in the next version of Firefox?

Patches are currently still in review. But if we can get it approved and merged soon (before December 2), then we can get that fix in for Nightly. :)
(However, not until much later for Firefox release)

Comment 10

[OpenMySourceCode]

(In reply to kpatenio from comment #9)

(In reply to OpenMySourceCode from comment #8)

So wait. Does this mean the fix is in the next version of Firefox?

Patches are currently still in review. But if we can get it approved and merged soon (before December 2), then we can get that fix in for Nightly. :)
(However, not until much later for Firefox release)

Will it show on here when the patch is included in nightly?

Comment 11

[kpatenio]

Sorry for lack of updates here (and for not being able to get this landed soon). Had this ticket on my radar for a while, but sadly did not have a chance to work on it further after encountering run-ins with failing intermittent tests. I intend to revisit this patch soon and try to figure out why it's raising issues with tests on Windows.

There will be a notification here when the patch has landed. After that, in the next Nightly update, the patch should be included.

Comment 12

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

The bug assignee didn't login in Bugzilla in the last 7 months.
:mconley, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 13

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

Looks like kpatenio will come back around to this (see comment 11).

Comment 14

[kpatenio]

Last time I tackled this (again), there were still issues with the test browser_resizeVideo.js on Windows builds. I recall the test only failing in headless mode when running locally on a Windows machine. Haven't had a chance to revisit this and figure out why (yet), for most of my focus lately has been on bug 1751505.

Comment 15

[Kai Mast]

I have an issue on YouTube where, whenever the resolution of the video is changes due to connection issues, PiP is terminated. I think adding a mechanism like the one described here could resolve this as well.

Comment 19

[Andy [:rgbcmy]]

Hi, I would like to work on this issue. My plan is to make the auto timeout configurable via new advanced preference items (as per bug 1920354), and also verify that it will automatically pick up newly added video tags.

Comment 20

[Andy [:rgbcmy]]

Looks like there are unreleased old patches too so I'll look through that functionality and see if I can re-implement it without the tests breaking

Comment 21

[Andy [:rgbcmy]]

Anything else I need to get this issue assigned to me to work on?

Comment 22

[Itiel]

(In reply to Andy [:rgbcmy] from comment #21)

Anything else I need to get this issue assigned to me to work on?

Submitting a patch via moz-phab will automatically assign the bug to you.

Comment 23

[Andy [:rgbcmy]]

Thanks. So the YouTube case (bug 1920354) is extremely trivial, just increasing EMPTIED_TIMEOUT_MS via a new pref item solves it. Obviously the Plex case is going to take longer. Should I submit the YouTube case first as a separate patch or wait until both cases are solved and submit a single patch? Also I'm thinking you'll probably want the default for the config item to be the original value (1 sec) and anyone who needs a longer timeout can change it (the side effect if a video element is cleared permanently the blank PIP window remains open for longer).

Comment 24

[Andy [:rgbcmy]]

Attachment: Bug 1611643 - Allow PiP to resume/autoplay on Plex and YouTube r=mconley

This patch ensures that videos which resume or autoplay next by clearing and repopulating the video src or by removing and re-adding the video element (such as sites like Plex and YouTube) will continue to play in a PiP window. Otherwise, after some time, close the PiP window.

This patch replaces unpublished patches D110412, D131710

Two new prefs are added for customization and debugging:

1. media.videocontrols.picture-in-picture.video-close.wait-for-seconds (time to wait for new video element, default 10 seconds)
2. media.videocontrols.picture-in-picture.video-close.check-interval-ms (interval duration for each check; default 1000ms or 1 second)

Comment 25

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 26

[Andy [:rgbcmy]]

Can someone help out review the patch? Review has been stalled for a while. Thanks.

Comment 27

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

Hey niklas,

It looks like the review on this patch has stalled out - do you still have cycles to look at it?

Comment 28

[Andy [:rgbcmy]]

As it's been a while should I merge to the latest code revision?

Comment 29

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

Yes, that would be helpful, thanks rgbcmy!

Comment 30

[Andy [:rgbcmy]]

Rebased to latest codebase revision.

Comment 31

[Andy [:rgbcmy]]

Is there someone else available to complete the review?

Comment 32

[Andy [:rgbcmy]]

Wondering if things are a bit quieter for everyone over there and there is someone able to pick up the review?