Closed Bug 1255475 Opened 4 years ago Closed 4 years ago

window content not rescaled properly when dragging a maximized window between hidpi & lodpi displays

Categories

(Core :: Widget: Win32, defect, major)

All
Windows
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox45 --- unaffected
firefox46 --- unaffected
firefox47 --- fixed
firefox48 --- fixed

People

(Reporter: jfkthame, Assigned: jfkthame)

References

Details

Attachments

(1 file)

Using Win8.1 or Win10 system having displays of different DPI scaling factors, maximize the Firefox window on one screen, then drag it by the titlebar to move to the other screen.

Result: window un-maximizes when dragged (as expected), but content is not rescaled appropriately for the new display.

Manually resizing the window again, or dragging it back across the display-resolution transition fixes the rendering.
I think that this can be marked as a major bug since has a very large impact to the user experience. Jonathan please change the severity back to normal if you think otherwise.
Severity: normal → major
OS: Unspecified → Windows
Hardware: Unspecified → All
When you start to drag a maximized window, Windows automagically restores it to the "normal" state. Messages that are dispatched to the window are first WM_ENTERSIZEMOVE (as for any window-frame drag), and then WM_SIZING (because it gets resized to its non-maximized state); eventually there'll be a WM_EXITSIZEMOVE (when you release the window).

The problem here arises because when we get WM_SIZING (after an initial WM_ENTERSIZEMOVE), the code in nsWindow treats this as beginning a "live-resize"; specifically, it sets mResizeState to RESIZING. And while we're in the RESIZING state, we do not automatically resize the window on WM_DPICHANGED (because normally this would mean the user is in the process of stretching the window across multiple screens, and overriding what the user is in the middle of doing makes for a bad experience).

To fix this, I've added a separate MOVING state for mResizeState, so that we can distinguish it from RESIZING in the case where we get ENTERSIZEMOVE, then SIZING (for the auto-restore) and then MOVING as the normal window is dragged around.
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Comment on attachment 8730217 [details] [diff] [review]
Don't treat a window as being live-resized when it is dragged from a maximized state, so that DPI rescaling will happen appropriately if we cross between displays

Review of attachment 8730217 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/windows/nsWindow.cpp
@@ +5357,5 @@
>      }
>  
> +    case WM_MOVING:
> +      FinishLiveResizing();
> +      mResizeState = MOVING;

I think FinishLiveResizing() should take a new resize state as a parameter.
r=me with this fixed or answered.
Attachment #8730217 - Flags: review?(VYV03354) → review+
(In reply to Masatoshi Kimura [:emk] from comment #5)
> I think FinishLiveResizing() should take a new resize state as a parameter.
> r=me with this fixed or answered.

Sounds good, I'll fix it that way.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d31bea45f96b53e25828b28b397e8dc6831d1e9b
Bug 1255475 - Properly distinguish 'moving' from 'resizing' state when a maximized window is dragged, resulting in a WM_SIZING message followed by WM_MOVING; this allows us to handle DPI rescaling during the move if necessary. r=emk
https://hg.mozilla.org/mozilla-central/rev/d31bea45f96b
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Comment on attachment 8730217 [details] [diff] [review]
Don't treat a window as being live-resized when it is dragged from a maximized state, so that DPI rescaling will happen appropriately if we cross between displays

Approval Request Comment
[Feature/regressing bug #]: 890156 & friends (per-monitor dpi)

[User impact if declined]: bad user experience when a maximized window is dragged on a multi-monitor Windows system with mixed hi- and lo-dpi displays

[Describe test coverage new/current, TreeHerder]: tested manually; no automated tests (we don't have mochitest running on multi-monitor, mixed-resolution configurations!), but this is on QA's radar as part of per-monitor dpi testing

[Risks and why]: minimal, this just makes us pay more careful attention to the messages Windows sends (resizing vs moving)

[String/UUID change made/needed]: none
Attachment #8730217 - Flags: approval-mozilla-aurora?
Comment on attachment 8730217 [details] [diff] [review]
Don't treat a window as being live-resized when it is dragged from a maximized state, so that DPI rescaling will happen appropriately if we cross between displays

This is planned for 47, Aurora+
Attachment #8730217 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Duplicate of this bug: 1339715
You need to log in before you can comment on or make changes to this bug.