macOS: child WKWebView cursor flickers when layered over host WKWebView

[cfool]

Description

On macOS, when a child webview created via WebViewBuilder::build_as_child / Tauri Window::add_child is layered over the main host WKWebView, the mouse cursor can flicker continuously while moving over cursor-sensitive elements inside the child webview.

The observed behavior is that the cursor alternates between the child webview's expected cursor, e.g. text over an <input> or pointer over a link/button, and the host webview's cursor, usually default.

This looks like both the host WKWebView and the child WKWebView are still participating in native cursor updates for the same screen area.

Environment

• OS: macOS 15.6.1, arm64
• Tauri: 2.11.1
• tauri-runtime-wry: 2.11.1
• wry: 0.55.1, locally patched from wry
• tao: 0.35.2
• Rust: 1.94.0

Reproduction Scenario

The app creates:

1. A main Tauri/WKWebView window that renders the app UI.
2. A child preview webview using Tauri Window::add_child, which reaches wry's WebViewBuilder::build_as_child.
3. The child webview is positioned over a rectangle in the host webview.
4. The child page contains cursor-sensitive elements:
   • <input> / <textarea> for text cursor
   • links/buttons/divs with cursor: pointer
   • normal areas with default cursor

When moving the mouse inside the child webview over an input or pointer region, the system cursor flickers between the child cursor and the host cursor.

Diagnostics Performed

We added temporary logging on both sides:

• Host webview: mousemove events continued firing while the pointer was visually inside the child preview rectangle.
• Child webview: mousemove events also fired continuously, with targets such as input.

Example observations:

• Child webview reported target input while the expected native cursor was text/I-beam.
• Host webview simultaneously reported movement over the underlying host DOM container.
• Applying pointer-events: none to the host DOM container did not stop the flicker and did not stop host-side logging.
• Forcing the host preview container to cursor: text stopped flicker over child input regions, but then the pointer test region started flickering between pointer and text.

This strongly suggests the problem is not DOM hit testing in the host page, but native cursor competition between overlapping WKWebView instances.

Suspected Cause

On macOS, build_as_child appears to add the child WKWebView as a subview of the window content view:

if is_child {
  ns_view.addSubview(&webview);
}

The main WKWebView is also a subview of the same parent view. The child webview is visually above the host webview, but the host WKWebView still covers the whole window and appears to keep contributing cursor rect / cursor update behavior underneath the child area.

I could not find any macOS-specific cursor rect or hit-test isolation logic in the current wry WKWebView subclasses. WryWebView seems to override keyboard, first mouse, drag/drop, and some mouse button handling, but not cursorUpdate:, resetCursorRects, addCursorRect, tracking areas, or hit testing for overlapped child regions.

Expected Behavior

When the mouse is over a child webview, only the topmost child webview should determine the native cursor for that area.

The host webview underneath should not update the cursor for pixels covered by the child webview.

Actual Behavior

The cursor flickers between the child webview's cursor and the underlying host webview's cursor during mouse movement.

Related Context

This is similar to a known class of OOPIF / layered webview problems where multiple native webviews are stacked and more than one layer tries to update the system cursor.

Related but not identical issues:

• Cursor bug on macOS #175
• Cursor not changing on winit #1333

Those are about macOS cursor behavior in wry, but I could not find an existing issue specifically tracking child WKWebView cursor flicker caused by overlapping host and child webviews.

Possible Fix Direction

A native fix may need to ensure that when child WKWebViews overlap the main WKWebView, the underlying host webview does not contribute cursor rects / cursor updates in the covered area.

Potential areas to investigate:

• Cursor rect invalidation for parent/host WKWebView when child webview bounds change
• Hit-test or cursor-update suppression for underlying webviews in covered regions
• A child-webview manager that ensures only the topmost interactive WKWebView under the mouse can drive cursor state