STR: 1. Open Gmail. 2. Zoom in (Ctrl-+/Cmd-+), to e.g. 150% 2. Click on "Compose" 3. Shift-Click on the Pop-out icon for the new message (next to the X/Save & Close icon) ACTUAL RESULTS: The New Message draft is moved to its own window. This window is displayed at 100% EXPECTED RESULTS: New window should be displayed at 150%. Note: Cmd-+ in the Pop-out zooms both the pop-out and the main window to 125%. Note: This was reported via email by Martin Kretzschmar of Google. I'm able to reproduce, using Nightly 48.0a1 (2016-03-14)
It is Firefox UI code which deals with this kinds of zoom levels.
Component: Layout → General
Product: Core → Firefox
This isn't 100% reproducible, but it tends to reproduce within a few attempts. (repeating steps 2 & 3 of STR). It also seems to reproduce more readily if I disable e10s, and in a profile that has background tabs open. There's probably a race condition of some sort involved.
Bug 1258056 may be relevant here in the e10s case. Bug 594140 is where we initially implemented looking at the opener page's zoom level to set the window zoom level if it's opened through window.open(). That may be the relevant code to look into here. I have also noted that in e10s mode, sometimes changing the zoom in one window/tab doesn't change the zoom in another window/tab displaying the same website, so there's also the possibility of the code syncing up the zoom levels based on content preferences being somehow broken.
See Also: → bug 1258056
2 years ago
Whiteboard: [platform-rel-Google] [platform-rel-Gmail]
Given comment 1, I'm going to ask Mike where this should be filed and/or what next steps would help move this forward.
Hey jaws, do you know who's got the most browser zoom stuff swapped into their head these days?
Flags: needinfo?(mconley) → needinfo?(jaws)
I don't know. Katie last worked on it (cc'ing), and I think right now it rests between Gijs and myself. I think it might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1300376 which had a fix but was backed out because it wasn't the most efficient.
This doesn't feel like a Core::DOM bug but it's also not Firefox::Location Bar ... any better suggestions for a component?
Bug 565718 is Firefox :: General, so I'll move it there.
Component: DOM → General
Product: Core → Firefox
Maybe Dolske knows someone who could take a look?
This seems to WFM in nightly today, though it's still broken on 52. Did this get fixed somewhere/somehow? Maybe bug 1297970?
Depends on: 1345375
This does indeed seem WFM in Nightly. Resolving as such. It'd be nice to know what fixed it, though, if anyone's up for tracking that down.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.