fix(windows): position child host windows in parent-client coordinates - #16
Merged
Merged
Conversation
Porting upstream PR pichillilorenzo#2768 turned the three internal WebView host HWNDs into WS_CHILD windows, but InAppWebView::setPosition kept passing screen coordinates to SetWindowPos. Those were correct for the previous owned top-level host, and are wrong for a child window, whose coordinates are relative to the parent client area. The host window therefore sat offset by the Flutter window origin, and every popup it owns went with it: <select> dropdowns, the print preview printer/color pickers and context menus all opened away from the WebView. The offset shifted with the window position, so it looked intermittent. Keyboard navigation was unaffected, which hid the cause. setPosition now passes the widget offset as-is. This also drops the hand-rolled frame arithmetic (GetWindowRect plus SM_CYCAPTION/SM_CYFRAME/SM_CXPADDEDBORDER), which mis-measured borderless windows and was never DPI-correct. Adds native_host_window_position_test.dart alongside the existing WS_CHILD coverage.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Porting upstream PR pichillilorenzo#2768 (
c568a24e) turned the three internal WebView host HWNDs intoWS_CHILDwindows.InAppWebView::setPositionwas not adjusted and kept passing screen coordinates toSetWindowPos:That was correct for the previous owned top-level host. For a child window
SetWindowPostakes coordinates relative to the parent's client area, so the host window ends up offset by the Flutter window's screen origin.Everything the host window owns moves with it:
<select>dropdowns, the print preview printer/color pickers, and context menus all open away from the WebView. Because the error tracks the window position, it changes as the window is moved or resized and reads as intermittent. Keyboard navigation is unaffected (no coordinates involved), which hides the cause.Measured on a real app window (client origin
(42,133)), the host HWND sat at(79,275)— offset by exactly the window origin plus the frame fudge.Fix
Pass the widget offset as-is. This also removes the hand-rolled frame arithmetic (
GetWindowRect+SM_CYCAPTION/SM_CYFRAME/SM_CXPADDEDBORDER), which mis-measured borderless windows and was never DPI-correct — it usedGetSystemMetricsrather thanGetSystemMetricsForDpi.Testing
native_host_window_position_test.dart— new, source-scanning in the same style asnative_host_window_style_test.dart: assertssetPositionpositions byscaled_x/scaled_yand does not reintroduce screen-space APIs.<select>dropdowns and the WebView2 print preview pickers open in the right place again.Note for hosts on a mirrored window: a parent with
WS_EX_LAYOUTRTLmeasures child coordinates from the right edge, so that style has to be off for child-relative positioning to land correctly.