[e10s](multi-e10s) Background tabs never apply new zoom level immediately and always cause twitching when I select them

NEW
Unassigned

Status

()

2 years ago
a year ago

People

(Reporter: arni2033, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox51 affected, firefox52 wontfix, firefox53 affected, firefox54 affected)

Details

(Whiteboard: [e10s-multi:-])

(Reporter)

Description

2 years ago
>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
There're 2 scenarios of this bug. I don't really know if it's possible to implement STR_2(ER)
(the same as STR_1(X)), so I also mentioned scenario (STR_1) when browser sets 100% trap.
Please only mark as wontfix if that insane twitching delay (STR_1) is intentional.


>>>
STR_1:  (multi-e10s)
0. Set pref "dom.ipc.processCount" to 100
1. Open http://www.vesti.ru/ in a new tab (Tab_1). Open http://www.vesti.ru/ in a new tab (Tab_2)
2. Switch to Tab_1, press Ctrl+"+"
3. Wait 1 minute, then switch to Tab_2

AR:
 First Tab_1 applies new zoom level (twitches on user demand), then after Tab_2 becomes selected,
 it also twitches when it applies new zoom level, because new zoom level was not applied in that tab
ER:  Either X or Y
 X) If it's possible for Tab_2 to update immediately and completely avoid twitching, it should do so
 Y) Not THAT huge delay. Tab_2 should update with some delay after Step 2, but with some sane delay
   (less than 1 minute, obviously), to avoid unwanted twitching in Step 3.



STR_2:  (e10s)
1. Open http://www.vesti.ru/ in a new tab (Tab_1). Open http://www.vesti.ru/ in a new tab (Tab_2)
2. Switch to Tab_1
3. Press Ctrl+"+", then once you see that the page applied new zoom level, immediately switch to Tab_2

AR:
 First Tab_1 applies new zoom level (twitches on user demand), then after Tab_2 becomes selected,
 it also twitches when it applies new zoom level, because new zoom level was not applied in that tab
ER:
 Only one twitching per changing zoom level. And in STR_2 that twitching should happen in Tab_1.
 What means that when user selects Tab_2, it should already apply new zoom level
(Reporter)

Updated

2 years ago
No longer blocks: 1277113
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID 	20170130030205

I was able to reproduce the issue on the latest Firefox Release (51.0.1) and on the latest Nightly (54.0a1).
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
Component: Untriaged → Panning and Zooming
Product: Firefox → Core
I think the key here is that the "twitching" happens when the tab is brought into the foreground, regardless of how much delay there is. We don't paint background tabs, so they don't get the new zoom level until they are brought into the foreground. This behaviour is intentional. To see why consider the case where a user has a thousand tabs open from the same site and changes the zoom on the foreground one, and then we spend then next few minutes repainting all the background tabs at the new zoom level while the user can't do anything.

That being said we might want to delay the paint on tabswitch so that we don't paint at the old zoom level. I think the aggressive painting is a result of e10s-specific changes. Maybe mconley has some thoughts on this.
Component: Panning and Zooming → DOM: Content Processes
ni?ing myself for comment 2.
Flags: needinfo?(mconley)
Whiteboard: [e10s-multi:?]
Guessing at a better component for this. Not blocking for e10s-multi.
Component: DOM: Content Processes → Graphics: Layers
Whiteboard: [e10s-multi:?] → [e10s-multi:-]
The page zoom code isn't perfectly architected for e10s, I'm afraid. We use the nsIContentPrefService2 to store the zoom preferences per site, and then we have this listener in the parent that waits for a the gBrowser to be "updated" (a new browser is selected):

http://searchfox.org/mozilla-central/rev/f5077ad52f8b90183e73038869f6140f0afbf427/browser/base/content/browser.js#4735-4736

Here's where it intercepts that update, and sets the zoom factor. In single-process mode, I'm guessing that happens before we have a chance to paint.

In e10s, especially with the force painting stuff we've got going on, by the time we get to this point in the code, we've already painted, so we're too late.

Chromium appears to have the same bug, incidentally.
Flags: needinfo?(mconley)
Based on comment 5 the root cause seems e10s-related. DOM::Content Process might not be right, but it's more e10s-related than Graphics::Layers, I think.
Component: Graphics: Layers → DOM: Content Processes
This seems like a frontend bug to me.
Component: DOM: Content Processes → Tabbed Browser
Product: Core → Firefox
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
You need to log in before you can comment on or make changes to this bug.