browser: in-page clicks unresponsive — HTML <select>, buttons, links all dead inside webview

[BunsDev]

Symptom

Inside the embedded browser pane (app/src/browser/), the rendered web content is completely non-interactive. Reproduced on main at 046d2efc, macOS 25.5.0:

• Clicking an HTML <button> or <a> element does nothing.
• HTML <select> dropdowns don't open.
• Form fields don't receive focus / keyboard input.
• Scrolling inside the page works (that's WKWebView's own gesture handling) but mouse clicks never reach the page.

This is distinct from PR #75 (close-leak + toolbar). #75 left this symptom explicitly unresolved because the root cause is not in app/src/browser/.

Root cause hypothesis

The WKWebView is attached as a child NSView of the GPUI canvas:

app/src/browser/webview_host.rs:135
  wry::WebViewBuilder::new_as_child(&parent)
                                    ^^^^^^^
                                    = active_appkit_view_handle()  // the GPUI canvas NSView

In AppKit, subviews normally receive mouse events on top of the parent. However custom-rendered NSViews (which is what the GPUI fork — warpui — uses to paint the canvas) almost always override hitTest:withEvent: to return self so the framework gets every event. When the parent returns itself from hitTest:, AppKit never tests subviews, so the WKWebView never sees the click.

Supporting evidence:

• app/src/browser/browser_view.rs:146-153 — NativeWebViewElement::dispatch_event() returns false unconditionally. GPUI doesn't forward events to the native view either.
• with_accept_first_mouse(true) is set on the wry builder (webview_host.rs:139), which would help — but only if AppKit hit-testing reached the webview at all.
• The user reports the entire page is dead, not just the edges; that points to occlusion/routing, not a bounds-mismatch (which would leave the center clickable).

Suggested investigation path

1. Look at the GPUI canvas NSView impl in crates/warpui/... — find the hitTest:withEvent: override and confirm it returns self unconditionally.
2. Decide between two fixes:
   • (A) Teach the GPUI canvas's hitTest: to consult a registry of native-child rects (managed by NativeWebViewElement::set_bounds) and return the appropriate subview when the click is inside one. Tightest fix; one framework change.
   • (B) Reparent the WKWebView from a child of the GPUI canvas to a sibling — i.e., add it directly to the window's contentView at a higher z-order than the canvas. Avoids the framework change but requires keeping bounds in window-coordinate space and managing visibility/focus interactions with GPUI.
3. Confirm by inspecting the responder chain and view hierarchy at runtime (view->printSubtree in lldb, or NSView debug logging).

Files touched

• app/src/browser/webview_host.rs — attach point (new_as_child, set_bounds, attach_if_needed).
• app/src/browser/browser_view.rs:146-153 — NativeWebViewElement::dispatch_event.
• crates/warpui/... — wherever the canvas NSView is defined (the actual hit-test routing).

Notes

• This blocks meaningful use of the embedded browser pane for any interactive site.
• Workaround: open URLs in the system browser instead.
• Out of scope for fix(browser): stop webview NSView leak on close + tighten toolbar #75 because that PR is app/src/browser/-only and this needs framework-level work in warpui.