With WebKit rendering into its own wl_subsurface, Wayland's input routing matters. winit currently sees ALL events because buffr's wl_surface owns the input region. For Phase 3 we need pointer + keyboard events to flow to WebKit when the cursor is over the browser region.
Current state
WebKit's wl_surface is a child of buffr's. By default the WebKit subsurface won't get any pointer events because the parent's input region covers everything.
Three approaches
A. Continue forwarding via existing wpe_event API (Recommended)
Keep using `wpe_event_pointer_*_new` + `wpe_view_event` that we already wired for OSR. winit fires events to buffr; buffr forwards to WebKit. No Wayland-level input routing changes needed. Simplest. Drawback: cursor shape is still buffr's responsibility (we have `take_cursor_change` for that).
B. wl_surface input region split
Set buffr's wl_surface input region to EXCLUDE the browser rect (`wl_surface::set_input_region`). Wayland then routes pointer events in the browser region directly to the WebKit subsurface. WebKit handles its own events natively. Drawback: split-brain — chrome events to winit, browser events to WebKit. Need to plumb keyboard focus carefully.
C. Hybrid
A for keyboard (always to WebKit when focused), B for pointer.
Recommended path
Start with A. Already works for OSR; nothing to change beyond ensuring `dispatch_pointer_*` keeps firing in supports_native mode (currently it dispatches to WebKit via WPEView regardless of how WebKit is rendering).
Scope
- Audit `dispatch_keyboard` / `dispatch_pointer_motion` / `dispatch_pointer_button` / `dispatch_axis` in `runtime.rs`. Confirm they work on `WPEViewWayland` (they should — same `wpe_view_event` API).
- Verify cursor delivery: in OSR mode we render the page bitmap and overlay our chrome cursor. In native mode WebKit composites natively; do we still need `take_cursor_change`? Probably yes for hover indication on links.
Acceptance
- Click on a link inside the browser region → WebKit navigates.
- Type into a text input → keypresses reach WebKit.
- Scroll wheel works.
Reference
With WebKit rendering into its own wl_subsurface, Wayland's input routing matters. winit currently sees ALL events because buffr's wl_surface owns the input region. For Phase 3 we need pointer + keyboard events to flow to WebKit when the cursor is over the browser region.
Current state
WebKit's wl_surface is a child of buffr's. By default the WebKit subsurface won't get any pointer events because the parent's input region covers everything.
Three approaches
A. Continue forwarding via existing wpe_event API (Recommended)
Keep using `wpe_event_pointer_*_new` + `wpe_view_event` that we already wired for OSR. winit fires events to buffr; buffr forwards to WebKit. No Wayland-level input routing changes needed. Simplest. Drawback: cursor shape is still buffr's responsibility (we have `take_cursor_change` for that).
B. wl_surface input region split
Set buffr's wl_surface input region to EXCLUDE the browser rect (`wl_surface::set_input_region`). Wayland then routes pointer events in the browser region directly to the WebKit subsurface. WebKit handles its own events natively. Drawback: split-brain — chrome events to winit, browser events to WebKit. Need to plumb keyboard focus carefully.
C. Hybrid
A for keyboard (always to WebKit when focused), B for pointer.
Recommended path
Start with A. Already works for OSR; nothing to change beyond ensuring `dispatch_pointer_*` keeps firing in supports_native mode (currently it dispatches to WebKit via WPEView regardless of how WebKit is rendering).
Scope
Acceptance
Reference