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

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Jonathan Kew [:jfkthame]]

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.

Comment 1

[Bogdan Maris, Desktop QA]

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.

Comment 2

[Jonathan Kew [:jfkthame]]

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.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: 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

Comment 4

[Jonathan Kew [:jfkthame]]

Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fcac06f8ac57

Comment 5

[Masatoshi Kimura [:emk]]

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.

Comment 6

[Jonathan Kew [:jfkthame]]

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

Comment 7

[Jonathan Kew [:jfkthame]]

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

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d31bea45f96b

Comment 9

[Jonathan Kew [:jfkthame]]

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

Comment 10

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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+

Comment 11

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8971ca6f81ed