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

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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

Comment 1

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Attachment: 1_move_to_secondary_monitor.png

Comment 2

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Attachment: 2_resize_on_secondary_monitor.png

Comment 3

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Attachment: 3_move_back_to_primary_monitor.png

Comment 4

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Attachment: 4_resize_on_primary_monitor.png

Comment 5

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I can also reproduce the bug on OS X 10.7.5.  So the OS X version doesn't seem to be a factor.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

The bug also happens with my tryserver build from bug 1189565 comment #42.  So yes, my patch for that bug is the trigger.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out
https://hg.mozilla.org/mozilla-central/rev/a6786bf8d71d

Comment 10

[Markus Stange [:mstange]]

(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.