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.

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.

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

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.

(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

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 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+