>>> 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
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
See Also: → bug 1089246
ni?ing myself for comment 2.
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.
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.