Full Page Zoom isn't initially honored in Gmail Compose pop-out windows

RESOLVED WORKSFORME

Status

()

Firefox
General
RESOLVED WORKSFORME
2 years ago
10 months ago

People

(Reporter: dholbert, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(platform-rel +, firefox48 affected)

Details

(Whiteboard: [platform-rel-Google] [platform-rel-Gmail])

(Reporter)

Description

2 years ago
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)

Comment 1

2 years ago
It is Firefox UI code which deals with this kinds of zoom levels.
Component: Layout → General
Product: Core → Firefox
(Reporter)

Comment 2

2 years ago
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.

Comment 3

2 years ago
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
Whiteboard: [platform-rel-Google] [platform-rel-Gmail]

Updated

2 years ago
platform-rel: --- → ?
Component: General → DOM
Product: Firefox → Core

Updated

2 years ago
platform-rel: ? → +
Rank: 8
Rank: 8 → 9
Given comment 1, I'm going to ask Mike where this should be filed and/or what next steps would help move this forward.
Flags: needinfo?(mconley)
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.
Flags: needinfo?(jaws)
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?
Flags: needinfo?(dolske)

Comment 10

11 months ago
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
Flags: needinfo?(dholbert)
(Reporter)

Comment 11

11 months ago
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
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME

Updated

11 months ago
No longer depends on: 1345375

Updated

10 months ago
Flags: needinfo?(dolske)
You need to log in before you can comment on or make changes to this bug.