Commit Graph
7 Commits
Author SHA1 Message Date
ZacharyZhang-NY 6e2bd20a9b T10.6: drop RGBA payload from the wire when the hardware path publishes a surface 2026-05-10 23:52:12 -04:00
ZacharyZhang-NY 9711167560 T13 diagnostic: T7 red is a TestAppContext hit_test quirk, not a prod bug
Three new diagnostics narrow T7 to test-mode infrastructure:

1. `diagnose_t7_hitbox_reachability_heatmap` (ignored, --nocapture):
   builds the real ElyShell, navigates to https://example.com/, then
   sweeps a 6×6 grid across the full 1920×1080 window dispatching
   mouse_move at each cell and recording hover_point. Result: **0 of
   36 grid cells trigger hover_point** — input_overlay's listener
   misses every position in the window, not just the viewport center.

2. Same test then dispatches a single MouseDown at the viewport
   center and reads back `focus_handle.is_focused`. Result: **true**.
   The root div's `track_focus` MouseDown bubble handler fires on
   the very same event. GPUI dispatch IS working at the root hitbox
   (`.size_full()`).

3. `baseline_overlay_after_gpui_component_init_receives_click` and
   `baseline_overlay_with_input_state_construction_receives_click`:
   replicate `gpui_component::init` and `InputState::new` +
   `subscribe_in` in isolation. Both still pass — neither breaks
   hit_test for an occlude div.

Together these isolate the failure to *something `ElyShell::new`
configures that interacts badly with `TestAppContext`'s simulated
executor*, after every individual ingredient passes. The user has
already confirmed (in the previous round) that "click works" after
the layout fix in 840255f lands in the real binary; the T7 red
guard is reproducing a test-mode quirk, not a production regression.

The red guard stays in the suite as documentation. Its `#[ignore]`
reason now records the diagnostic outcome so the next reader doesn't
re-walk the same bisect. Two paths forward (recorded in the
attribute):
  (a) reproduce the bug outside TestAppContext and file upstream
  (b) route web canvas input through the root div + a viewport-bounds
      gate, which sidesteps hit_test for input_overlay entirely

(b) is structurally more complex than it looks because backdrops
(workspace disclosure, hidden-sidebar overlay) sit in z-order in
front of input_overlay and don't `stop_propagation` — implementing
a clean root-level fallback requires teasing apart the cases. Not
done in this commit.

cargo test --bin ely_app: 120 passed, 0 failed, 2 ignored.
cargo test --bin ely_app -- --ignored: 1 fail (T7 red) + 1 pass
(diagnostic, which just prints the heatmap and reports findings).
2026-05-10 20:13:19 -04:00
ZacharyZhang-NY 94194e933e Document T13 bisect probes: capture phase bug is in ElyShell::new
T13 (the still-red `user_click_in_rendered_web_canvas_reaches_input_pipeline`
guard) is now backed by five bisect probes that each reproduce one
slice of the real ElyShell render tree and assert the listener combo
still receives a simulated click. Every probe passes:

  * baseline_overlay_div_receives_simulated_click — GPUI primitives
  * baseline_overlay_with_full_listener_combo_receives_click — exact
    listener combo (on_mouse_down + capture_any_mouse_up +
    on_mouse_move + on_scroll_wheel) on a single .occlude() div
  * baseline_overlay_under_overflow_hidden_relative_receives_click —
    the relative + overflow_hidden wrapper render_web_surface uses
  * baseline_overlay_under_full_elyshell_wrapper_chain_receives_click —
    root → absolute-flex container → main-pane → content-wrapper
    → surface-wrapper chain
  * baseline_overlay_with_canvas_sibling_receives_click — adds the
    canvas viewport_tracker sibling
  * baseline_overlay_with_entity_update_in_mouse_down_receives_click —
    on_mouse_down's bubble fires entity.update (auto-notify) before
    MouseUp dispatches
  * baseline_overlay_under_root_with_track_focus_receives_click —
    the full chain wrapped in a root div with track_focus +
    on_mouse_up(Left, bubble)

The red guard meanwhile reports `hover_point = None` after
`simulate_mouse_move`, meaning input_overlay's `on_mouse_move`
also never fires — so the failure mode isn't capture-specific.
ALL of the overlay's listeners share the same `hitbox.is_hovered`
check, and it returns false in the real ElyShell tree but true in
every probe. Whatever the difference is, it is in
`ElyShell::new`'s setup (BrowserCore, Entity<InputState>,
SliderState, subscriptions, `start_external_web_surface_timer`'s
detached task) or in the `sync_address_input` call that
`navigate_active_tab` runs through Input's `set_value` — none of
which the probes touch.

The probes stay in the suite as both documentation (they encode
what is *not* the bug, narrowing the search for the next round)
and as regression guards (a future change that breaks them is a
real new regression in plain layout, not in the still-elusive
ElyShell-specific bug). Tests run as 118 passed + 1 ignored;
`cargo test -- --ignored` continues to fail with the same T7 red
guard. T13 is intentionally still in progress.
2026-05-10 19:49:51 -04:00
ZacharyZhang-NY 7f3b8b42b3 Dedup identical RGBA payloads against the last frame's Arc<RenderImage>
WebSurfaceFrame::from_parts was unconditionally calling
Arc::new(RenderImage::new([image::Frame::new(image_buffer)])) on
every live frame, even when the underlying bytes were
byte-for-byte identical to the previous frame. At 60 fps on a 1080p
canvas that was ~960 MB/s of host-side cloning plus a fresh GPUI
texture allocation on every tick — the bottleneck Linus + Karpathy
+ Jony flagged as the next material step after dropping the
file-system pixel pipe (a80d039).

A thread_local single-slot cache in web_surface_frame.rs now keys
on a 64-bit DefaultHasher of the raw RGBA bytes. On a cache hit
the existing Arc<RenderImage> is reused; on a miss the buffer is
built once, stored, and returned. Steady-state idle pages stop
churning the GPUI texture pool entirely. Hash collisions are
1 in 2^64 — if that ever becomes a real worry, the cache key can
be widened to length + a sample of bytes before paying the full
memcmp; not worth doing today.

The T10 red guard
(identical_live_frames_share_render_image_arc) drops its
#[ignore] attribute outright per the contract it documented.
The T7 red guard (user_click_in_rendered_web_canvas_reaches_input_pipeline)
remains ignored — it's a separate diagnosis tracked under T13.

cargo test --bin ely_app: 113 passed, 0 failed, 1 ignored
(was 112+2, T10 guard went green).
cargo test --bin ely_app -- --ignored: 1 failed (only T7 click
pipeline remains red).

Follow-ups (left for the endgame T10 IOSurface path):
  * a per-tab cache would prevent multi-tab switching from
    thrashing the single slot; defer until a real multi-tab
    scroll benchmark shows it matters.
  * the endgame is OffscreenRenderingContext + IOSurface so the
    GPU texture itself is the source of truth and the host-side
    Vec<u8> + ImageBuffer + RenderImage allocation chain
    disappears entirely.
2026-05-10 19:36:08 -04:00
ZacharyZhang-NY 414ba3d158 Land a red TDD guard for live-frame texture re-upload (T10)
Every `WebSurfaceFrame::from_live_frame` today calls
`Arc::new(RenderImage::new([image::Frame::new(image_buffer)]))`
unconditionally — even when the underlying RGBA bytes are
byte-for-byte identical to the previous frame. At 60 fps on a 1080p
canvas that is roughly 960 MB/s of host-side cloning + a fresh
GPUI texture upload, and the roundtable agreed it is the next
material bottleneck after the file-system pipe (a80d039).

The contract this test pins is the cheapest invariant we can hold
against today's `SoftwareRenderingContext`: two `ServoLiveFrame`
inputs whose `rgba_bytes` are bit-identical must produce the same
underlying `Arc<RenderImage>` instance. Today they do not; the
ignored run confirms two distinct pointer values for back-to-back
identical inputs.

The fix has two recognised shapes. The interim shape lives entirely
in `WebSurfaceFrame::from_parts`: remember the previous frame's
bytes (hash or pointer-eq) and reuse the existing `Arc<RenderImage>`
when they match. The endgame shape removes the host-side image step
entirely — `OffscreenRenderingContext` + IOSurface — at which point
the assertion becomes meaningless and is replaced by a frame-time
budget. Whichever lands first, the fix commit MUST delete the
`#[ignore]` attribute outright; toggling its reason is a broken
contract.

To call `WebSurfaceFrame::from_live_frame` from a unit test without
spawning a real sidecar process, `ServoLiveFrame` gains a
`#[cfg(test)] pub(crate) fn for_test(...)` constructor that wraps
the existing private `from_parts` with realistic defaults. No
production path uses it.

cargo test --bin ely_app: 112 passed, 0 failed, 2 ignored.
cargo test --bin ely_app -- --ignored: 2 failed (expected RED:
T7 click pipeline + T10 texture re-upload).
2026-05-10 19:32:43 -04:00
ZacharyZhang-NY 7b2b6daee9 Land a red TDD guard for the rendered-canvas click pipeline (T7)
After 840255f put the input overlay on-screen and a80d039 dropped
the file-system pixel pipe, the two harness baselines confirm:

  * `.occlude() + capture_any_mouse_up` works in TestAppContext
    (baseline_overlay_div_receives_simulated_click)
  * `input_overlay`'s exact listener combo works in isolation
    (baseline_overlay_with_full_listener_combo_receives_click)

…and the layout regression guard confirms the overlay is now drawn
inside the visible window. Yet running a real ElyShell, navigating
to https://example.com/, and dispatching a real MouseDown/MouseUp at
the geometric center of the measured viewport STILL leaves
WebSurfaceStore.click_point as None. The capture phase listener is
being eaten somewhere strictly inside the real ElyShell widget tree.

`user_click_in_rendered_web_canvas_reaches_input_pipeline` encodes
this contract in user terms — "click on the rendered page and the
input pipeline records it" — without naming a GPUI mechanism. The
test is marked `#[ignore]` so the rest of the suite stays green; the
attribute carries the full reproduction note so a reader picking the
ticket up later doesn't have to rediscover what we already know
(layout + pixel-pipe both clean, listener combo clean, suspicion now
on sibling z-order / ancestor stop_propagation / overflow_hidden
content_mask clipping the overlay's hitbox).

The fix commit must DELETE the attribute outright; toggling the
ignore reason is a broken contract. Running
`cargo test -- --ignored user_click_in_rendered_web_canvas_reaches_input_pipeline`
today reproduces the failure with click_at = (1106, 567) inside
viewport_bounds (309, 71, 1594, 992).

cargo test --bin ely_app: 112 passed, 0 failed, 1 ignored.
cargo test --bin ely_app -- --ignored: 1 failed (expected RED).
2026-05-10 19:13:46 -04:00
ZacharyZhang-NY 840255f88c Lift the web canvas out of in-flow so the input overlay lands on screen
A GPUI harness boots a real ElyShell, navigates to an external URL, and
asks the input_overlay's sibling canvas tracker where it laid out. On
main before this change the canvas reports

    Bounds { origin: (309, window_height - 17), size: (W - 326, content_h) }

i.e. the overlay's top edge sits at the very bottom of the visible
window. Every user click in the visible area lands above (or beside)
the overlay; the on_mouse_down + capture_any_mouse_up listeners never
even see the event because the hitbox is off-screen. Twelve commits
chased focus/coords/outcome enums on the sidecar side while every click
in the live shell hit empty space.

Root cause: in render_web_surface the rendered web image (img / loading
div / error page) was a non-absolute child of a `.relative().size_full()`
wrapper. The non-absolute child claims `size_full` block-flow height
inside that wrapper, which made the wrapper's intrinsic height
content_height + content_height. The two `.absolute().size_full()`
siblings (viewport_tracker, input_overlay) then sized against that
inflated parent and were positioned in the bottom half — exactly
content_height below where they were supposed to be.

Fix: keep the relative wrapper as the layout owner of the panel slot
(size_full, overflow_hidden, min_w_0) and put the rendered image into
an absolute `inset_0` child of its own. viewport_tracker and
input_overlay stay as absolute siblings. With the image out of in-flow
the wrapper sizes to its parent and the overlay's hitbox lands at
y = top of content area (71 in a 1080-tall window) instead of
y = window_height - 17.

GPUI test harness (`gpui_harness_tests.rs`) is the holdout set:
  - `baseline_overlay_div_receives_simulated_click` proves GPUI's
    occlude + capture_any_mouse_up primitive works under TestAppContext.
  - `baseline_overlay_with_full_listener_combo_receives_click` proves
    the exact listener combo render_input_overlay uses works in
    isolation.
  - `ely_shell_external_canvas_lays_out_inside_window` boots a real
    ElyShell, navigates, and asserts the overlay's measured bounds fit
    inside the visible window. Without the fix above, this test trips
    on bounds extending below the window bottom.

The three new store-layer tests in web_surface_tests.rs pin per-tab
isolation, zero-delta short-circuit, and resize-mid-drain decoupling
invariants the harness work flushed out.

ely_app picks up gpui's test-support feature as a dev-dependency so the
harness can use VisualTestContext + simulate_mouse_*.

cargo test --bin ely_app: 112 passed (was 108 + 4 new harness/store tests).

Remaining work (not in this commit): even with the layout fixed, the
harness shows MouseUp's capture_any_mouse_up still doesn't fire on the
ElyShell tree, while MouseDown's bubble does. Some sibling/ancestor
listener in the live shell is eating the MouseUp capture phase that
the standalone listener-combo baseline does not. Tracked separately.
2026-05-10 17:38:10 -04:00