When the frame handles a DPI change, doesn't always use the WM_DPICHANGED suggestion rect
Reported by
ekosch...@gmail.com,
Dec 19 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Steps to reproduce the problem: 1. Have two monitors, each with a different DPI 2. Maximize chrome window to the high DPI monitor 3. Ensure chrome is in foreground, use windows key + shift + arrow to apply 'monitor migration' hotkey to the chrome window What is the expected behavior? Chrome window should end up maximized to the other monitor. What went wrong? Chrome handled a DPI change, was given the new monitor's maximize rect in the lParam of the DPI change, but did something other than call SetWindowPos using the unmodified suggestion rect. If a window handles a DPI change by doing anything other than taking the suggestion rect as-is, there is a chance the window will end up in the wrong place, the way chrome is ending up not fully maximized to it's monitor after migrating to another monitor that causes a DPI change. Did this work before? N/A Chrome version: 63.0.3239.84 Channel: n/a OS Version: 10.0 Flash Version: While this specific scenario hasn't always worked in Windows, it has always been the case that you should never ever modify the suggestion rect during WM_DPICHANGED. Everyone, as part of making a complicated windows app scale per monitor, tries to modify the suggestion rect. Everyone tries, everyone eventually realizes the right thing to do during this message is to blindly accept the new window pos. Chrome, please stop being fancy with you WM_DPICHANGED handler and always take our rect. Thx.
,
Dec 27 2017
Tested this issue on 63.0.3239.84 using windows 10 -- two monitors with same DPI and unable to reproduce this. 1. Maximized chrome window in one monitor >> Ensured it is in foreground 2. Used win key + shift + arrow and chrome browser is seen in maximised state in another monitor. As both the systems are of same DPI, issue is not reproducible. As ET team doesn't have different DPI machines forwarding this issue to Inhouse. Could someone from Inhouse team take a look into this. Thanks!
,
Dec 27 2017
Obviously if the two monitors are set to the same DPI, there'd be no DPI change. Also, you do not need special h/w, just go to settings->display and set the two monitor's DPI to two non equal values. When chrome became PM aware, they started handling WM_DPICHANGED. The only way to do this successfully in all scenarios is to call SetWindowPos using the unmodified RECT that's in the lParam for the message. Chrome is not always using the exact rect sent by the system, and as a result does not behave perfectly when moved or sized very near the DPI boundary. A bug was recently fixed that addressed this problem for 'well behaving PM aware applications' like notepad (which take our suggestion rect blindly). Please try the repro on the most recent build possible, and first try with notepad. Assuming chrome repros the issue and notepad does not, please try using the unmodified suggestion rect sent with WM_DPICAHNGED. I'd be very interested to know what chrome is doing to calculate their new size/ position on DPI changes, and why they believe they should be doing this (though I'm sure that regardless of the reason I'd still suggest just taking Window's suggestion rect).
,
Jan 2 2018
Thanks for the update! Tested in chrome #63.0.3239.84 and stable #63.0.3239.108 and canary #65.0.3309.0 on Win 10.0 able to reproduce the issue. Unable to provide the per revision bisect so providing the normal bisect.Below are the Bisect Details Good build:54.0.2807.0(Revision:407480). Bad build:54.0.2808.0(Revision:407658). You are probably looking for a change made after 407502 (known good), but no later than 407510 (first known bad). CHANGE-LOG URL: --------------- https://chromium.googlesource.com/chromium/src/+log/f7789f833aa26bc38fe4a74276b0a57c45ca3c65..48e079d573d6385fab6ad7110475a2b9da913bab Suspecting : https://chromium.googlesource.com/chromium/src/+/23364eecc5d1bb1770f8c22a7c0a320154e3eac7 From the CL above, assigning the issue to the concern owner @robliao: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner. Review-URL: https://codereview.chromium.org/2175693004 Note: Windows specific issue.
,
Jan 23 2018
,
Aug 1
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Dec 19 2017