web_snapshot O(tree-size) slow: enrichNodeWithLocatorBounds does per-node locator round-trips (~5s budget-cap on heavy pages)

[basementbot]

Summary

Capturing screen state on a DOM-heavy page (e.g. a flight-search results page, ~8k DOM nodes) is dramatically slower than it should be — on the order of ~9–12 s, vs ~1.5 s for the accessibility-only path on the same page. Profiling shows the cost is entirely in per-node Playwright locator round-trips during view-hierarchy bounds enrichment, not in the DOM/JS work.

Root cause (profiled)

jstack-sampling the running daemon during a capture shows the hot method is:

xyz.block.trailblaze.playwright.PlaywrightScreenState.enrichNodeWithLocatorBounds

enrichNodeWithLocatorBounds recurses the ~thousand-node view-hierarchy tree and, for every node, makes individual Playwright locator round-trips:

PlaywrightAriaSnapshot.resolveElementRef(page, ElementRef(descriptor, nth))
locator.count()
locator.boundingBox(...)

That's ~2–3 CDP round-trips × N nodes. It's budget-capped at ENRICHMENT_BUDGET_MS = 5_000L, so on heavy pages it burns the entire 5 s budget and still returns partial/incomplete bounds (the "enrichment budget exceeded — returning partial bounds" log).

Evidence (isolated Playwright benchmark, same page, ~8.3k DOM nodes)

A) per-node handle.boundingBox() × 800 nodes:        304 ms   (0.4 ms/node, 1 round-trip)
B) batched getBoundingClientRect over ALL 8316 nodes:  5 ms   (one page.evaluate)
→ 61× on boundingBox alone

The real code does ~3 round-trips per node over the full tree, which is why it saturates the 5 s budget. Batching the whole tree into one page.evaluate is ~1000× fewer round-trips.

For reference, the individual DOM ops are all cheap (measured on the same page): full-DOM walk + getComputedStyle on all 8386 elements ≈ 24 ms; computedRole/computedName reads ≈ 1 ms; ariaSnapshot ≈ 55 ms; screenshot ≈ 75 ms. None of these are the cost — it is exclusively the per-node locator RPC fan-out.

Suggested fix

Resolve all node bounds in a single batched page.evaluate (a getBoundingClientRect pass over the resolved elements) instead of per-node locator round-trips. The role/name/nth → element resolution already exists batched in BATCH_VIEWPORT_CHECK_JS (used by computeElementVisibility for the annotation overlay) — so the same bounds are effectively computed twice today (once batched for the overlay, once per-node for the tree). Reuse the batched result for the tree.

Keep the existing per-node locator.boundingBox() only as a fallback for nodes whose batched DOM rect is zero-size — that's the Compose-Web-Wasm case the locator path exists for (accessibility overlay elements have zero-size DOM rects but valid positions in Playwright's a11y tree). On such pages the fallback set is small, so the fan-out is bounded.

Expected impact: view-hierarchy enrichment on heavy pages drops from ~5 s (budget-capped, partial bounds) to ~single-digit ms (complete bounds).

Repro

Capture screen state (any path that enriches the view hierarchy with bounds) on a large, dynamic results page and profile the daemon thread — enrichNodeWithLocatorBounds dominates. A ~1000+ node tree is enough to hit the 5 s budget cap.

[basementbot]

Candidate fix: main...basementbot:trailblaze:fix/199-batch-viewhierarchy-bounds

Approach: resolve all view-hierarchy node bounds in ONE batched page.evaluate (reusing BATCH_VIEWPORT_CHECK_JS's role/name/nth → element resolution), keyed by descriptor#nth. Keep the per-node resolveElementRef + boundingBox locator path as a fallback for nodes the batch doesn't cover — notably the Compose-Web-Wasm a11y-overlay elements (zero-size DOM rect, valid a11y position) the locator path exists for.

Benchmark (isolated Playwright, real DOM-heavy page, ~256-node aria tree, faithful per-node count()+boundingBox()):

per-node aria-locator round-trips × 256:   252 ms  (0.98 ms/node)
batched getBoundingClientRect (1 round-trip):  4 ms
→ 63×

Profiling the running daemon (jstack during a capture) shows the per-node path is the hot method and saturates the 5s ENRICHMENT_BUDGET_MS, returning partial bounds — so real-world impact is ~5s → ~4ms.

Not yet runtime-validated end-to-end (compiles clean; my local compose-jar build was inconsistent so I couldn't run it through the daemon). Please validate on CI, specifically: (1) that the tree-traversal descriptor#nth ordering aligns with BATCH_VIEWPORT_CHECK_JS's roleNameMap nth-indexing (both are pre-order DFS, but worth confirming so bounds aren't misassigned), and (2) that the Compose-Web-Wasm fallback still fires for zero-DOM-rect nodes.

[basementbot]

Huge-DOM scaling benchmark (synthetic 30,000-node page — where the per-node path becomes catastrophic):

per-node (2 round-trips):  0.46 ms/node → ~13,710 ms for all 30,000 nodes
batched getBoundingClientRect (all 30,000):     13 ms
→ ~1055×

Confirms the current path is O(N) browser round-trips: on a 30k-node tree it's ~13.7 s — well past the 5 s ENRICHMENT_BUDGET_MS, so it returns very partial bounds. The batched fix is a single round-trip (~13 ms) regardless of DOM size (O(1) round-trips). The heavier the page, the bigger the win — ~63× on a real ~256-node flight-results tree, ~1000× on a 30k-node page.