Autoplayed next video should also be PIP

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.

¡Hola!

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

Updating flags accordingly FWIW.

¡Gracias!
Alex

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

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.

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.

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

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

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

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.

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.

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

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.

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.

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.

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

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

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

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

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)

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

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

Hey niklas,

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

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

Yes, that would be helpful, thanks rgbcmy!

Rebased to latest codebase revision.

Is there someone else available to complete the review?

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

Partial fix for autoplay on some sites/youtube static ads by adding a config option to disable PiP close on empty video src. Defaults to old behaviour for compatibility.

I've created this small patch that maybe can be used as the first step to fixing this bug until reviewers have time for the more comprehensive fix.

https://hg.mozilla.org/mozilla-central/rev/6b1f1d35b83e

Seems like this could be worth a relnote callout? Please nominate if you agree!

Hm, requires a pref flip in order to get this behaviour. I don't think we should relnote it just yet.