b61359cb40
During window position restore the ScreenWin::DIPToScreenRect function
is called (at least) twice. Early on it is called with nullptr for hwnd
and it does the correct calculations, using Chrome's cached copy of
monitor resolutions in DPI and screen pixels. Later on it is called with
a non-zero hwnd and it uses Windows functions and they give incorrect
results on multi-monitor setups with variable DPI. Specifically the DPI
of monitor zero is used for all of the adjustments. This may be because
our hwnd is not yet properly set up (we are, after all, calculating
where we should put it) or it may be a Windows bug or quirk.
The HWND parameter is needed in some cases, specifically when handling
Windows OS TSF IME in a window that spans monitors with different DIP
settings, however no cases were found where the
ScreenWin::DIPToScreenRectInWindow function needs to pass a non-NULL
hwnd. Therefore this function is modified to always pass nullptr which
maintains correct behavior of IME, even in the edge cases, while fixing
window-restore behavior (tested with the Chrome task manager).
Some edge case bugs around tooltips were found and separate bugs were
filed for those.
Testing: Manually tested for the window-restore fix and for correct
cross-monitor OS IME behavior.
Bug: 1224715
Change-Id: I3efc366e986d6e08df8dbffcee8d7ab8257939d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2989185
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Robert Liao <robliao@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#902720}
This directory contains UI frameworks used to build various user interface features. This directory it not intended to contain UI features (such as a keyboard).