Revert "Mac: Always return original frameRect in constrainFrameRect"

Commit: d6834320 | 2025-11-19 22:36:08+00:00

← Back to List

Revert "Mac: Always return original frameRect in constrainFrameRect"

Moderate
Commit Hash: d68343203e98ff445c30825cca270993d5ec53ed
Commit Time: 2025-11-19 22:36:08+00:00
Impact Level: Moderate
Generated By: webview2-upstream-sentry
Upstream Review: View Upstream Review 🔗

📋 Summary

This commit reverts a previous modification to the NativeWidgetMacNSWindow::constrainFrameRect:toScreen: method. The reverted code simplified this method's logic to directly return the original frameRect for all windows, completely disabling AppKit's menu bar collision handling. After the rollback, conditional logic is restored: constraints are only disabled for headless windows and macOS 26+ systems, while other cases still call the superclass's default implementation. Related unit test modifications are also reverted, including the removal of the newly added views_test_base_mac.mm test helper file, and restoration of anchor rectangle adjustment logic in bubble_dialog_delegate_view_unittest.cc tests. The rollback reason is that the original change is suspected of causing interactive_ui_tests failures on Mac.

🎯 Impact Analysis

This rollback has a moderate impact on WebView2Mac. It affects the constrainFrameRect:toScreen: method of Remote Cocoa's core window class NativeWidgetMacNSWindow, which controls window screen boundary constraint behavior. WebView2Mac's HostingNSWindowBridge inherits from NativeWidgetNSWindowBridge, which uses NativeWidgetMacNSWindow as its underlying window implementation.

Specific impacts:
1. **Window Positioning Behavior Change**: After rollback, child windows (such as Omnibox, bubbles, dialogs, etc.) on non-headless and non-macOS 26+ systems will be subject to AppKit's menu bar collision detection again. This means these windows may be automatically shifted down by the system to avoid colliding with the menu bar area when in fullscreen or maximized state, even if they have large shadows.

2. **WebView2Mac Child Window Impact**: If child windows are created in WebView2Mac host applications (e.g., find bar, date picker, context menus), their positioning on macOS 13-25 may be affected by system menu bar collision handling, potentially causing unexpected window positions.

3. **Headless Mode Protection**: The rolled-back code still retains special handling for headless windows (_isHeadless check), ensuring test environment windows are not constrained by screen boundaries. This is beneficial for WebView2Mac testing scenarios.

4. **macOS 26 Compatibility Maintained**: The rolled-back code preserves special handling for macOS 26+, still bypassing AppKit's automatic adjustments on newer systems, helping maintain consistent window behavior on future macOS versions.

5. **Potential Layout Issues**: The original modification was to fix unexpected Omnibox shifting in fullscreen windows with vertical tabs (Bug 461532423). After rollback, this issue may reoccur in certain configurations, affecting similar UI component layouts in WebView2Mac.

It is recommended to closely monitor the impact of this rollback on WebView2Mac child window positioning, especially for floating windows with shadows (such as autocomplete popups, dropdown menus) in fullscreen/maximized states. If positioning issues are discovered, additional window positioning logic may need to be added at the HostingNSWindowBridge layer to compensate.

Impacted Classes:

NativeWidgetMacNSWindow remote_cocoa::NativeWidgetNSWindowBridge