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

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[arni2033]

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

Comment 1

[Ciprian Muresan [:cmuresan], Ecosystem QA]

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

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 3

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

ni?ing myself for comment 2.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Guessing at a better component for this. Not blocking for e10s-multi.

Comment 5

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

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.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This seems like a frontend bug to me.

Comment 8

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.