Moving Firefox from Retina to non-Retina display breaks the window display

RESOLVED FIXED in Firefox 43

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: FlorinMezei, Assigned: KWierso)

Tracking

({regression})

43 Branch
mozilla43
All
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox43 fixed)

Details

Attachments

(4 attachments)

(Reporter)

Description

3 years ago
Reproducible with: latest Firefox 43 Nightly (BuildID: 20150901030226)
Reproducible on: Mac OS X 10.9.5, with a MacBook Pro Retina 15-inch, late 2013, and a secondary monitor connected via HDMI. 

Steps to reproduce:
1. Start Firefox on the primary monitor (MacBook's retina display).
2. Move Firefox window to the secondary monitor.
---> the window will display partially (missing buttons, truncated toolbar/titlebar/content) - see "1_move_to_secondary_monitor.png"
3. Resize the Firefox window on the secondary monitor.
---> the window recovers correctly - see "2_resize_on_secondary_monitor.png" 
4. Move Firefox window back to the primary monitor.
---> the window will display "zoomed out" with empty white space - see "3_move_back_to_primary_monitor"
5. Resize the Firefox window on the primary monitor.
---> the window recovers correctly - see "4_resize_on_primary_monitor.png" 

Expected results: moving the window between monitors should not affect its UI.

Actual results: moving the window causes content to zoom in/out, causing buttons to disappear and rendering the window almost unusable.

This is a regression caused by fix in bug 1189565.

m-c:
Last good revision - 2015-08-30 - 7db14bebae9196d780b1d64d2fd32d1bda26828b
First bad revision - 2015-08-31 - f2518b8a7b97b5bb477e94bc9131584007aac887
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7db14bebae9196d780b1d64d2fd32d1bda26828b&tochange=f2518b8a7b97b5bb477e94bc9131584007aac887

m-i:
20:22.98 LOG: MainThread Bisector INFO Last good revision: 292d13beeb7b984dfa4effe685f2681dc1b2e941
20:22.98 LOG: MainThread Bisector INFO First bad revision: 2e731191c6920f29f12b4592466f9a4dc2df1842
20:22.98 LOG: MainThread Bisector INFO Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=292d13beeb7b984dfa4effe685f2681dc1b2e941&tochange=2e731191c6920f29f12b4592466f9a4dc2df1842
(Reporter)

Comment 1

3 years ago
Created attachment 8655954 [details]
1_move_to_secondary_monitor.png
(Reporter)

Comment 2

3 years ago
Created attachment 8655955 [details]
2_resize_on_secondary_monitor.png
(Reporter)

Comment 3

3 years ago
Created attachment 8655957 [details]
3_move_back_to_primary_monitor.png
(Reporter)

Comment 4

3 years ago
Created attachment 8655958 [details]
4_resize_on_primary_monitor.png
I can reproduce this, testing with the same m-c nightly (yesterday's) on OS X 10.9.5, using a mid 2012 Retina MacBook Pro attached to a non-Retina display.  I see it with APZ off or on, with e10s off or on, and even with hardware acceleration off or on.  So clearly we've got to do something about it -- if all else fails, we'll need to back out my patch for bug 1189565.

But equally clearly, my patch for bug 1189565 was correct (at least in a general way) -- we do need to send Gecko a resize event when the backing scale factor changes.  Maybe the timing was off, though.  Or maybe it's just that we've accumulated a lot of cruft over the years, subconsciously working around the absence of a resize event, and we need to find that cruft and remove it.

What do you think, Markus?

I'll play around with this a bit.  But if we do need to find and remove a lot of cruft, I doubt I'll have time for it before I retire at the end of this month.  Especially considering that most of this cruft is likely to be in cross-platform (Gecko) code, with which I'm not terribly familiar.
Flags: needinfo?(mstange)
I can also reproduce the bug on OS X 10.7.5.  So the OS X version doesn't seem to be a factor.
The bug also happens with my tryserver build from bug 1189565 comment #42.  So yes, my patch for that bug is the trigger.
I've asked KWierso (the current sheriff) to back bug 1189565 out on m-c.

After playing around for a couple of hours, I still haven't found any leads on this bug.
(Assignee)

Comment 9

3 years ago
Backed out
https://hg.mozilla.org/mozilla-central/rev/a6786bf8d71d
Assignee: nobody → wkocher
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
(In reply to Steven Michaud [:smichaud] from comment #5)
> But equally clearly, my patch for bug 1189565 was correct (at least in a
> general way) -- we do need to send Gecko a resize event when the backing
> scale factor changes.  Maybe the timing was off, though.  Or maybe it's just
> that we've accumulated a lot of cruft over the years, subconsciously working
> around the absence of a resize event, and we need to find that cruft and
> remove it.
> 
> What do you think, Markus?

I agree. I don't have any ideas on what's going wrong.
Flags: needinfo?(mstange)
You need to log in before you can comment on or make changes to this bug.