1896172 - Dragged tab into a new window causes is to be treated as a background tab (may freeze with QoS enabled when under high load)

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Kris Wright :KrisWright]

Steps to reproduce:

• Must be running under high load
  = Have two firefox windows open
  = Have tab in the background (not foreground window atm)
  = Drag into other window; tab added as a foreground tab
  = Enter the window. Tab should freeze

I think the problem here is that we aren't setting the QoS priority of the dragged tab to the foreground. So when we switch to the dragged tab, it's still running at the lowest priority and we freeze. A profile showing QoS markers for the repro will give us more details.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

non-shipping issue though I believe it can impact nightly users (?)

Comment 2

[BugBot [:suhaib / :marco]]

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

Comment 3

[Haik Aftandilian [:haik]]

Following Dennis' steps on bug 1901603 comment 15 (without the pref change), the incorrect process priority is 100% reproducible for me on Mac and Linux. I haven't tested Windows. Dragging a tab off the tab bar to create a new window leaves the dragged tab in the background priority level. Steps:

1. Create a window with two tabs, a mozilla.org tab and a wikipedia.org tab
2. Make the wikipedia tab active
3. Drag the wikipedia tab off the tab bar and drop it to create a new window

The profiler shows the wikipedia tab being moved to background process priority. On Mac Nightly, if MOZ_LOG=QoSPriority:4 is enabled, the QosPriority messages show the wikipedia tab being put into the background QoS.

More debugging needed.

Comment 4

[Markus Stange [:mstange]]

Hi Mike, I'm guessing this has to do with tabbrowser code that sets tabs to active/inactive. Do you know who could work on this?

Comment 5

[Mike Conley (:mconley) (:⚙️) (PTO Aug 24-28)]

I might be able to, but I think I need more information. Is merely setting the isActive property to true on the browsingContext the only thing I need to do to influence the priority of the process from the front-end? Like, how is priority generally influenced?

Comment 6

[Florian Quèze [:florian]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)

I might be able to, but I think I need more information. Is merely setting the isActive property to true on the browsingContext the only thing I need to do to influence the priority of the process from the front-end?

I think the answer is yes, but I'll let Markus answer. One thing I wanted to point out is that we have profiler markers showing process priority changes, both in the parent and the content processes, so it should be possible to verify quickly if the process priority did change when you change something in the code.

Comment 7

[Andrew McCreight [:mccr8]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)

I might be able to, but I think I need more information. Is merely setting the isActive property to true on the browsingContext the only thing I need to do to influence the priority of the process from the front-end? Like, how is priority generally influenced?

Yes, I think that is right. Only on the top level BC for the tab. There's also the priorityHint property on remoteTab which can be used to affect the priority, but in this specific case the tab being pulled out ends up in the foreground so it does seem like setting isActive makes sense.

Comment 8

[Markus Stange [:mstange]]

I think the first step to diagnose this would be to see if the logging from browser.tabs.remote.logSwitchTiming shows anything interesting.

(In reply to Mike Conley (:mconley) (:⚙️) (PTO: July 22-26) from comment #5)

Is merely setting the isActive property to true on the browsingContext the only thing I need to do to influence the priority of the process from the front-end? Like, how is priority generally influenced?

I'm not sure. I haven't investigated this in depth yet.

Comment 9

[Greg Stoll :gstoll]

I can reproduce the underlying issue on Windows - the ProcessPriorityLog shows that the pulled-out tab has BACKGROUND priority. But the AsyncTabSwitcher logging seems to indicate that the tab is marked as isActive, so I don't think that's the issue. I'll keep investigating.

Comment 10

[Markus Stange [:mstange]]

Thank you for investigating this!

Comment 11

[Greg Stoll :gstoll]

Attachment: Bug 1896172 - Correctly set tab priority after moving to new window r=nika!

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/11bd6a38f3dd
Correctly set tab priority after moving to new window r=nika

Comment 13

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/11bd6a38f3dd