Open Bug 1005972 Opened 6 years ago Updated Last year
poorly resized window after wake-from-sleep with non-retina external monitor
I came across a bug report on twitter today here: https://twitter.com/shinypb/status/463350666484658176 The user is on Aurora 30 on a retina MBP with an external non-retina monitor. The problem occurs as follows: 1. FF on external non-Retina monitor. 2. Sleep machine 3. Unplug monitor 4. Wake machine 5. Tiny unusable FF window shows up. I assume this is a case of the user having their laptop closed and just wanted to grab it and go without waking it up to gracefully disconnect the monitor.
See also these comments in bug 794038: https://bugzilla.mozilla.org/show_bug.cgi?id=794038#c5 https://bugzilla.mozilla.org/show_bug.cgi?id=794038#c55 That was two years ago, though. Did we regress?
See Also: → 794038
I can't reproduce this, on either OS X 10.7.5 or 10.9.2. I tested with FF 29 (the current release).
:bkelly - could you check whether the user has tried starting in Safe Mode and/or running with a fresh profile? Also, does the problem also happen with Release (FF29), or is it a new regression in Aurora?
(In reply to Jonathan Kew (:jfkthame) from comment #3) > :bkelly - could you check whether the user has tried starting in Safe Mode > and/or running with a fresh profile? Also, does the problem also happen with > Release (FF29), or is it a new regression in Aurora? He reports: 1) It does happen with FF29 2) It does not happen with safe mode in Aurora He's not using any addons, though, so not sure why safe mode would help in this case.
(In reply to Ben Kelly [:bkelly] from comment #4) > (In reply to Jonathan Kew (:jfkthame) from comment #3) > > :bkelly - could you check whether the user has tried starting in Safe Mode > > and/or running with a fresh profile? Also, does the problem also happen with > > Release (FF29), or is it a new regression in Aurora? > > He reports: > > 1) It does happen with FF29 > 2) It does not happen with safe mode in Aurora > > He's not using any addons, though, so not sure why safe mode would help in > this case. It'd be good to check about:support to see what modified preferences there are in his profile - maybe something there is affecting the behavior.
(In reply to Jonathan Kew (:jfkthame) from comment #5) > It'd be good to check about:support to see what modified preferences there > are in his profile - maybe something there is affecting the behavior. So I misread this and asked him to look at about:config. When it wasn't easily obvious what changed there I asked him to use profile manager to create a new profile. He can no longer reproduce in either the new or old profile. :-\ I asked him to send me about:support pastebin if it occurs again.
Since the user can no longer reproduce I'm going to mark this WFM. I'll re-open if he reports it again.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
I was told on IRC (by spohl) to attach about:support to the bug
I can also reproduce this simply by unplugging my Thunderbolt display when Firefox 29 is running.
I've attached a screenshot where the minimize/maximize buttons are tiny (and the fullscreen button is in the wrong place). I've also seen it happen where the tabs themselves are tiny.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Markus, do tiny minimize/maximize buttons sound familiar to you?
Not in a way that lets me come up with a patch right away ;-) Somebody who can reproduce this needs to find out whether the "scale" variable in nsChildView::UpdateTitlebarCGContext() has the right value, and if not, why not. I don't really have time for this at the moment, unfortunately.
I'm happy to take a look next week in my free time, but if someone who knows the code has time, that'd of course be better.
Do the buttons redraw at the right size if you hover them, or if window focus changes? If that's the case, we're just not invalidating on the BackingScaleFactor change. Calling NotifyDirtyRegion(RectContainingTitlebarControls()) from nsChildView::BackingScaleFactorChanged() would probably fix that.
I have seen this same problem twice, with the same sequence of events to make it happen. See the attached screenshot. I am using release version 31.0 on OSX 10.9.4.
I also just saw this on Mac OS X Yosemite 10.10 when dragging a FF 33.1 window from an external Thunderbolt display to my Macbook Pro 13" retina display, without putting the Mac to sleep or disconnecting the external monitor.
I am having a similar problem with Firefox and Windows 10. Whenever my system goes in to sleep mode, my Firefox window is resized (smaller)when I wake the system. I have the latest fixes for both Firefox and Windows 10. I am using a Lenovo Z50 laptop and an Acer 23inch external monitor (SNID: 13600767043).
(In reply to Kevin Simons [:kevsim] (Telenor) from comment #10) > I can also reproduce this simply by unplugging my Thunderbolt display when > Firefox 29 is running. This WFM with both release Fx50 and latest Nightly on macOS 10.12. However, I am using the HDMI port on the MBP, instead of a Thunderbolt port. For those able to reproduce this, are you using Thunderbolt to connect to the external monitor?
Priority: -- → P3
Tracy, I apologize the not being tech savvy enough to know the name of the port I am using for my external monitor, it is the standard cable used for monitors for at least the last 40 years, I thought it was called C2G ? It is definitely not HDMI. Again, I am running Windows 10 accepting updates automatically on a Lenovo Z50 laptop and have release 50 of Firefox installed. I ONLY use the external Acer monitor (and not the laptop monitor) When I wake my system from SLEEP mode, my Firefox window is smaller (narrower, perhaps 1/3 as wide) than when I was viewing before SLEEP mode.
Henry, No worries, Thunderbolt is a Mac thing. Anyway, I think the Windows version of this bug that you're experiencing is included in bug 1292339.
Thanks Tracy, I'll try to join that conversation.
You need to log in before you can comment on or make changes to this bug.