Autoplayed next video should also be PIP
Categories
(Toolkit :: Picture-in-Picture, enhancement, P3)
Tracking
()
People
(Reporter: yoasif, Assigned: rgbcmy, NeedInfo)
References
(Blocks 2 open bugs)
Details
Attachments
(3 files)
Seen this asked for on various places, but also experienced a desire for this myself.
- Start watching a series on Plex or Netflix
- Enter PIP
- 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•5 years ago
|
||
¡Hola!
Just experienced this in Nightly and it is in fact a bit jarring.
Updating flags accordingly FWIW.
¡Gracias!
Alex
Comment 3•5 years ago
|
||
Udemy.com is also affected by this bug when viewing course videos.
Comment 4•5 years ago
|
||
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•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 8•4 years ago
|
||
So wait. Does this mean the fix is in the next version of Firefox?
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
(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)
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
|
||
(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•3 years ago
|
||
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•3 years ago
|
||
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•3 years ago
|
||
Looks like kpatenio will come back around to this (see comment 11).
Comment 14•3 years ago
|
||
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•3 years ago
|
||
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.
Updated•3 years ago
|
Assignee | ||
Comment 19•10 months ago
|
||
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.
Assignee | ||
Comment 20•10 months ago
|
||
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
Assignee | ||
Comment 21•10 months ago
|
||
Anything else I need to get this issue assigned to me to work on?
Comment 22•10 months ago
|
||
(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.
Assignee | ||
Comment 23•10 months ago
|
||
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).
Assignee | ||
Comment 24•9 months ago
|
||
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:
media.videocontrols.picture-in-picture.video-close.wait-for-seconds
(time to wait for new video element, default 10 seconds)media.videocontrols.picture-in-picture.video-close.check-interval-ms
(interval duration for each check; default 1000ms or 1 second)
Updated•9 months ago
|
Comment 25•8 months ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee | ||
Comment 26•8 months ago
|
||
Can someone help out review the patch? Review has been stalled for a while. Thanks.
Comment 27•6 months ago
|
||
Hey niklas,
It looks like the review on this patch has stalled out - do you still have cycles to look at it?
Assignee | ||
Comment 28•6 months ago
|
||
As it's been a while should I merge to the latest code revision?
Comment 29•6 months ago
|
||
Yes, that would be helpful, thanks rgbcmy!
Updated•6 months ago
|
Assignee | ||
Comment 30•6 months ago
|
||
Rebased to latest codebase revision.
Assignee | ||
Comment 31•5 months ago
|
||
Is there someone else available to complete the review?
Assignee | ||
Comment 32•24 days ago
|
||
Wondering if things are a bit quieter for everyone over there and there is someone able to pick up the review?
Description
•