Closed Bug 1201053 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Widget: Cocoa, defect)

43 Branch
All
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox43 --- fixed

People

(Reporter: FlorinMezei, Assigned: KWierso)

References

Details

(Keywords: regression)

Attachments

(4 files)

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
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.
Backed out
https://hg.mozilla.org/mozilla-central/rev/a6786bf8d71d
Assignee: nobody → wkocher
Status: NEW → RESOLVED
Closed: 4 years ago
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.