Closed Bug 1247272 Opened 4 years ago Closed 4 years ago

Incorrectly sized window controls on OS X hidpi display when primary monitor is non-hidpi

Categories

(Core :: Graphics, defect)

Unspecified
macOS
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1256576
Tracking Status
firefox47 + fixed
firefox48 --- fixed

People

(Reporter: jfkthame, Assigned: snorp)

References

Details

(Whiteboard: gfx-noted)

Attachments

(1 file)

Configuration:
Retina MacBook Pro with non-hidpi external display.
Monitors arranged side-by-side (I have the external display on the left, but I don't think this affects the issue).
Menu bar (in Sys Prefs / Displays / Arrangement) dragged to the external (non-hidpi) display.

Launch current mozilla-central build (Nightly 2016-02-09 does not show the bug, but I expect it to appear in Nightly 2016-02-10). Window opens on the primary (external) display.

Drag the window across to the Retina screen.

Result: the close/minimize/maximize buttons at the top left of the window, and the full-screen arrows that should be at the top right, are all incorrectly sized (visually half-sized, not scaled to 2x for the Retina resolution); and the full-screen arrows are also misplaced. See attached screenshot.

This appears to be a regression from bug 1243418. I confirmed that backing out 866edb59ba09 from my local m-c build fixes the problem.
Whiteboard: gfx-noted,regression
Looking into it...
Assignee: nobody → snorp
I can't seem to repro here on El Capitan.
Interesting; I'm currently running 10.9.5. Possibly OS version-dependent, then?
Duplicate of this bug: 1256318
Duplicate of this bug: 1258444
If it can help, I can reproduce it on El Capitan 10.11.3
Additional details/observations: it happens regardless of which of my displays is selected as primary display.
Duplicate of this bug: 1256526
Duplicate of this bug: 1250082
[Tracking Requested - why for this release]:
4 dupes - lots of people seeing this, we shouldn't ship this.

:snorp : FWIW, if you're still having issues reproducing, from one of the dupes:

(In reply to Dirkjan Ochtman (:djc) from comment #1)
> This definitely happens when disconnecting from my external monitor (i.e. Fx
> gets moved from non-HiDPI screen to HiDPI screen).

maybe this helps?
Flags: needinfo?(snorp)
See Also: → 1139593
Regarding reproducing this bug: AFAICT, it occurs only when e10s is DISabled, and hardware acceleration is ENabled. Others who have been seeing the problem, can you confirm this?
I believe the patch awaiting review in bug 1256576 will fix this.

There's a try build in progress at https://treeherder.mozilla.org/#/jobs?repo=try&revision=62ae6747aa1d, for anyone who would like to test the fix.
(In reply to Jonathan Kew (:jfkthame) from comment #11)
> Regarding reproducing this bug: AFAICT, it occurs only when e10s is
> DISabled, and hardware acceleration is ENabled. Others who have been seeing
> the problem, can you confirm this?

I confirm that e10s is disabled.

As per hardware acceleration, do you mean: media.hardware-video-decoding.enabled;true
If that is not the setting, let me know where to find that answer and I'll post back here.
(In reply to Alex Davis [:adavis] from comment #13)

> As per hardware acceleration, do you mean:
> media.hardware-video-decoding.enabled;true
> If that is not the setting, let me know where to find that answer and I'll
> post back here.

I meant hardware-accelerated rendering (not media decoding), exposed as the "Use hardware acceleration when available" option in Preferences / Advanced.

To confirm it's active, in the Graphics section of about:support, you should see something like "GPU Accelerated Windows: 1/1 OpenGL (OMTC)".
I'm fairly sure that I see this with e10s *enabled*. Not sure about hardware acceleration, will check tomorrow.
I see: "GPU Accelerated Windows	3/3 OpenGL (OMTC)"
It is also enabled in my Preferences.
Tracked for 47 as per-monitor DPI is on the release roadmap.
I have 1/1 OpenGL (OMTC) for GPU accelerated windows, and e10s is enabled.
Dirkjan, are you still seeing this in the latest Nightly and/or Aurora (builds later than at least 03/25)?
Flags: needinfo?(dirkjan)
My March 24th build isn't updating so far today.
Flags: needinfo?(dirkjan)
Huh, that's odd: my 03/23 Aurora build also says it's up-to-date; yet downloading a fresh copy from mozilla.org gives me 03/28.

I guess maybe we don't push out updates on a daily basis for the aurora channel? Please re-test once you do get updated, and confirm whether this is fixed for you (or you could use a manually-downloaded aurora or nightly).
I chose to shave the yak and ended up in #releng. Apparently updates are currently disabled, there's no bug for it.
Flags: needinfo?(snorp)
In 47.0a2 (2016-03-28), it looks good to me now.
OK, thanks. I'm going to resolve this as a dupe of bug 1256576; it was just another symptom of the same code bug.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1256576
Keywords: regression
Whiteboard: gfx-noted,regression → gfx-noted
You need to log in before you can comment on or make changes to this bug.