Fix frame constraint logic for macOS child windows
Moderate
Commit Hash:
4f0076b98b86ae59a2e719f7cc4a2546478d36e2
Commit Time: 2025-11-25 19:16:22+00:00
Impact Level: Moderate
Generated By: webview2-upstream-sentry
Upstream Review:
View Upstream Review 🔗
📋 Summary
This commit relands the fix from r1547376, but scopes the constrainFrameRect override to only apply to child windows. It modifies the constrainFrameRect:toScreen: method in NativeWidgetMacNSWindow class, simplifying the previous conditional logic for headless windows and macOS 26+ to a unified check: if the window is headless or has a parentWindow, return the original frameRect directly, bypassing AppKit's default menu bar collision handling. This prevents child windows with large shadows (such as the Omnibox) from being unexpectedly shifted down by the system in fullscreen/maximized states. The commit also removes related test helper code (views_test_base_mac.mm and the GetSystemReservedHeightAtTopOfScreen method) and updates unit tests to eliminate dependencies on system reserved height calculations.
🎯 Impact Analysis
This change has a **moderate impact** on WebView2Mac. The main impacts are reflected in the following areas:
**1. Core Window Positioning Logic Changes:**
WebView2Mac manages windows by inheriting from remote_cocoa::NativeWidgetNSWindowBridge, and NativeWidgetMacNSWindow is its underlying NSWindow implementation. This modification directly changes the behavior of the constrainFrameRect:toScreen: method, which is the core method AppKit uses to constrain window positions to avoid collisions with system UI elements like the menu bar.
**2. Impact on Child Windows:**
The modified logic bypasses system frame constraints for all windows with a parentWindow. WebView2Mac may create child windows in various usage scenarios (e.g., popup menus, dropdowns, dialogs). These child windows will no longer be subject to AppKit's default menu bar collision detection. This is generally beneficial for WebView2Mac as it allows more precise window positioning control, especially in fullscreen or maximized scenarios.
**3. Potential Edge Cases:**
- If WebView2Mac's host application creates child windows with large shadow areas (similar to the browser's Omnibox), this modification will prevent these windows from being unexpectedly shifted down.
- However, if WebView2Mac relies on the system's automatic position adjustment to avoid overlapping with the menu bar, this modification may cause child windows to overlap with the menu bar in certain situations.
**4. Test Infrastructure Simplification:**
The removal of the GetSystemReservedHeightAtTopOfScreen method indicates that upstream no longer needs to simulate system reserved area height in tests. This simplifies test logic, but also means that if downstream WebView2Mac tests depend on this method, they will need corresponding adjustments.
**5. macOS Version Compatibility:**
The original implementation had special handling for macOS 26+, now unified to return the original frameRect for all cases with a parent window. This may affect window positioning behavior consistency across different macOS versions.
**Recommended Actions:**
- Test WebView2Mac child windows (such as popup menus, dialogs) positioning in fullscreen and maximized modes to ensure correctness
- Check for any child windows unexpectedly overlapping with the menu bar or other system UI
- If downstream has custom window positioning logic, verify its compatibility with the new constraint logic
- If downstream test code uses GetSystemReservedHeightAtTopOfScreen, update the test code accordingly
**1. Core Window Positioning Logic Changes:**
WebView2Mac manages windows by inheriting from remote_cocoa::NativeWidgetNSWindowBridge, and NativeWidgetMacNSWindow is its underlying NSWindow implementation. This modification directly changes the behavior of the constrainFrameRect:toScreen: method, which is the core method AppKit uses to constrain window positions to avoid collisions with system UI elements like the menu bar.
**2. Impact on Child Windows:**
The modified logic bypasses system frame constraints for all windows with a parentWindow. WebView2Mac may create child windows in various usage scenarios (e.g., popup menus, dropdowns, dialogs). These child windows will no longer be subject to AppKit's default menu bar collision detection. This is generally beneficial for WebView2Mac as it allows more precise window positioning control, especially in fullscreen or maximized scenarios.
**3. Potential Edge Cases:**
- If WebView2Mac's host application creates child windows with large shadow areas (similar to the browser's Omnibox), this modification will prevent these windows from being unexpectedly shifted down.
- However, if WebView2Mac relies on the system's automatic position adjustment to avoid overlapping with the menu bar, this modification may cause child windows to overlap with the menu bar in certain situations.
**4. Test Infrastructure Simplification:**
The removal of the GetSystemReservedHeightAtTopOfScreen method indicates that upstream no longer needs to simulate system reserved area height in tests. This simplifies test logic, but also means that if downstream WebView2Mac tests depend on this method, they will need corresponding adjustments.
**5. macOS Version Compatibility:**
The original implementation had special handling for macOS 26+, now unified to return the original frameRect for all cases with a parent window. This may affect window positioning behavior consistency across different macOS versions.
**Recommended Actions:**
- Test WebView2Mac child windows (such as popup menus, dialogs) positioning in fullscreen and maximized modes to ensure correctness
- Check for any child windows unexpectedly overlapping with the menu bar or other system UI
- If downstream has custom window positioning logic, verify its compatibility with the new constraint logic
- If downstream test code uses GetSystemReservedHeightAtTopOfScreen, update the test code accordingly
Impacted Classes:
remote_cocoa::NativeWidgetMacNSWindow
remote_cocoa::NativeWidgetNSWindowBridge