1912672 - Auto Picture-In Mode causes a page freeze after opening a new tab and moving that new tab over to another screen.

Status: VERIFIED FIXED

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

Description

[AMD97]

Attachment: Screenshot 2024-08-11 112650.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

Steps to reproduce:

-Open a video
-Open a new tab
-Drag tab to another screen or separate it into a new window
-The video page source will freeze and will no longer be loaded.

Actual results:

After dragging a new tab over to another screen or using it to open a new window with Auto Picture-In mode enabled the source page of the video freezes and or bugs out resulting in the video still playing but the page no longer being loaded (See screenshot).

Expected results:

After dragging a new tab over to another screen or using the tab to open a new window, Auto Picture-In should collapse back into the page source and the page should be back to normal.

Comment 1

[AMD97]

Specific Firefox Version is Beta 130.0b3. I am assuming on Nightly 131 this also happens but not sure.

Comment 2

[Daniel Bodea [:danibodea]]

We have managed to reproduce this issue in Windows 10/11, MacOS11/14 and Ubuntu 22 using these steps:

1. Open the browser and enable PiP auto-trigger.
2. Play a YT video (longer than 45s)
3. Open a new tab.
4. Drag the new tab out of the window OR Right-click the new tab and choose the context menu option "Move tab" -> "To new window"
   (Such that the tab with the source video is coming in the foreground, but it does not get focus)

Actual: The tab with the source video is frozen while still playing the sound of the video. Refreshing the frozen page does not resolve the issue, but closing the tab and restoring it resolves it.

Expected: The tab with the source video does not get frozen.

Note: A second monitor/screen is not necessary to reproduce this bug, but it is somewhat of an edge case.

Comment 3

[AMD97]

(In reply to Daniel Bodea [:danibodea] from comment #2)

We have managed to reproduce this issue in Windows 10/11, MacOS11/14 and Ubuntu 22 using these steps:

1. Open the browser and enable PiP auto-trigger.
2. Play a YT video (longer than 45s)
3. Open a new tab.
4. Drag the new tab out of the window OR Right-click the new tab and choose the context menu option "Move tab" -> "To new window"
   (Such that the tab with the source video is coming in the foreground, but it does not get focus)

Actual: The tab with the source video is frozen while still playing the sound of the video. Refreshing the frozen page does not resolve the issue, but closing the tab and restoring it resolves it.

Expected: The tab with the source video does not get frozen.

Note: A second monitor/screen is not necessary to reproduce this bug, but it is somewhat of an edge case.

Yes and as of right now the only way to prevent this from happening is to simply just pause the video before you move a new tab to another window. Also I did mention in the full post that another screen isn't just causing it, but I should have changed the title to make that more clear.

Comment 4

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

Hey Daniele, have you had a chance to look at this one?

Comment 5

[Daniele Ferla]

Hi Mike :)

I tried to see what the issue is during this weekend, but I couldn't underpin anything specific (also I'm having some problems with the Browser Toolbox).

On top of the issue, I noticed that, once the bug has been triggered, I can see that the spinner animation appears everytime I load a new page. Maybe there is something going awry not just tab-wise, but browser-wise!

Comment 6

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

We're hitting an edge-case / bug in AsyncTabSwitcher, where the pendingpaint attribute is incorrectly still set on the <browser>.

Comment 7

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

Attachment: Bug 1912672 - Count STATE_LOADING tabs as pending even if they are in the do-not-deactivate set. r?#tabbrowser-reviewers!

Among other things, the postActions method in AsyncTabSwitcher attempts to do update
"auxiliary state" once the primary state (the various STATE_ flags in particular)
have been set.

Part of its job then is to loop over the current set of tabs and determine how
many we're still waiting on to do something asynchronous (like complete loading
or complete unloading).

We have a condition that is meant to skip counting any backgrounded that should
not be set to STATE_UNLOADING because they're either being used for print preview or
Picture-in-Picture (which requires that their DocShells stay active). However,
this condition didn't take into account the possibility that such a tab is
still in the STATE_LOADING state - meaning that we're still waiting for it
to finish being composited. This meant that in certain conditions, we'd
erroneously conclude that there weren't any more tabs to wait for, and
we'd "finish", preventing the STATE_LOADING tab from ever exiting the
"pendingpaint" condition.

This patch makes it so that we only skip counting those tabs if they're in the
STATE_LOADED state.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f27a5c12d72a
Count STATE_LOADING tabs as pending even if they are in the do-not-deactivate set. r=tabbrowser-reviewers,dao

Comment 9

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/f27a5c12d72a

Comment 10

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

The patch landed in nightly and beta is affected.
:mconley, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox131 to wontfix.

For more information, please visit BugBot documentation.

Comment 11

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

Since this is still an experimental opt-in feature, I'm willing to let this fix ride the trains.

Comment 12

[Daniel Bodea [:danibodea]]

This fix has been verified in Windows 10, Mac OS 14 and Ubuntu 22.