Wayland subsurfaces are stacked above their parent by default. WebKit's subsurface will cover any buffr-chrome pixels in the browser region. For things that need to overlay the page (omnibar dropdown, hint mode labels, find-in-page highlight bar, loading anim, permission prompt) we need them composited ABOVE the WebKit subsurface.
Approaches
A. Sibling subsurface for overlays
Create a second subsurface (`buffr_overlay_surface`) whose parent is the same winit wl_surface. Use `wl_subsurface::place_above(webkit_subsurface)` to stack it on top. Render overlays into this surface using a small wgpu offshoot OR a software-blit buffer.
B. Bring overlays to chrome strip only
Restrict overlays so they don't OVERLAY the browser region. Permission prompt + omnibar dropdown live in the chrome strip area where the chrome subsurface (= wgpu parent) is visible. Acceptable design constraint.
C. Don't composite WebKit when overlay active
Hide the WebKit subsurface (`wl_subsurface::place_below(parent)` is not a thing; use `set_visible`-style via a transparent buffer attach OR `wl_surface::commit` with a null buffer). Reveal when overlay closes.
Recommended
B for v1 — keeps Phase 3 scope manageable. File a follow-up for A once Phase 3 is stable.
Scope
- Audit all overlay code in apps/buffr-app/src/main.rs that paints into the browser region (`paint_chrome_strips` confirm strips only; `loading_anim::paint` — that's the big one).
- For `supports_native() == true`:
Out of scope
- Sibling subsurface for above-page overlays (approach A) — separate follow-up ticket.
Acceptance
- Open omnibar over a Wayland-native WebKit page → dropdown appears.
- Hint mode → labels appear on chrome strip (if visible there) OR are deferred to follow-up.
- Loading anim doesn't fight with WebKit's subsurface.
Reference
Wayland subsurfaces are stacked above their parent by default. WebKit's subsurface will cover any buffr-chrome pixels in the browser region. For things that need to overlay the page (omnibar dropdown, hint mode labels, find-in-page highlight bar, loading anim, permission prompt) we need them composited ABOVE the WebKit subsurface.
Approaches
A. Sibling subsurface for overlays
Create a second subsurface (`buffr_overlay_surface`) whose parent is the same winit wl_surface. Use `wl_subsurface::place_above(webkit_subsurface)` to stack it on top. Render overlays into this surface using a small wgpu offshoot OR a software-blit buffer.
B. Bring overlays to chrome strip only
Restrict overlays so they don't OVERLAY the browser region. Permission prompt + omnibar dropdown live in the chrome strip area where the chrome subsurface (= wgpu parent) is visible. Acceptable design constraint.
C. Don't composite WebKit when overlay active
Hide the WebKit subsurface (`wl_subsurface::place_below(parent)` is not a thing; use `set_visible`-style via a transparent buffer attach OR `wl_surface::commit` with a null buffer). Reveal when overlay closes.
Recommended
B for v1 — keeps Phase 3 scope manageable. File a follow-up for A once Phase 3 is stable.
Scope
Out of scope
Acceptance
Reference