[SawyerHood]

Summary

• Defer the sidebar swipe recognizer's horizontal-scroll-region probe off the tap path. It now runs at most once per gesture, at the first touchmove that shows horizontal intent — never on pointerdown/touchstart.
• Keep the probe on the wheel path, but only after the direction test, so vertical trackpad scrolls stop paying it.
• Add regression tests: the tap path performs zero forced-layout reads, and a swipe that starts inside a horizontal scroll region still yields to native scroll.

Fixes #1269

Root cause

The mobile swipe recognizer listens for pointerdown and touchstart on document (capture). On every tap it called isInsideHorizontalScrollRegion, which pairs getComputedStyle(...).overflowX with a scrollWidth/clientWidth read for each ancestor. Each pair forces a synchronous style + layout pass of the whole document, and the handler runs for both events, so one tap paid the flush twice. On a large streamed thread (un-virtualized timeline, styles dirty almost every frame) that flush blocks a mobile main thread for seconds — which also freezes the running animations, exactly as reported.

The path became hot in #1026, which replaced the blanket data-no-sidebar-swipe opt-out on message prose with runtime arbitration. After that, taps on prose — most of the mobile screen — fell through to the expensive walk.

Performance

Measured in Chromium at a 390×844 viewport against a 7.5k-node DOM inside SidebarInset, with styles dirtied before each tap (as a streamed thread does), 15 trials per variant on the same DOM:

Variant	Tap dispatch median	Tap dispatch max
Before	75.3 ms	110.7 ms
After	~0 ms	0.5 ms

The pre-fix cost equals one full forced style+layout flush (~75–95 ms on a desktop CPU); phone CPUs are several times slower and real threads have far more nodes, which produces the multi-second freezes in the issue.

Behavior verification

In a real browser at a compact viewport: a right swipe over message prose still opens the sidebar; a swipe that starts inside a horizontally scrollable region still does not.

Testing

• pnpm exec turbo run typecheck --filter=@bb/app
• pnpm exec turbo run test --filter=@bb/app — 326 files, 2,459 tests pass, including two new regression tests in sidebar.test.tsx.

🤖 Generated with Claude Code

[SawyerHood]

🚨 SLOP COP 🚨 · review

I am the Slop Cop. I am reviewing this pull request for security, code quality, performance, architecture, and product behavior.

I will post one final review after the parallel checks finish.

[SawyerHood]

🚨 slopcop/review — Cancel the swipe if startTarget is no longer connected before this deferred probe.

A live timeline update can replace the target between the gesture start and the first horizontal move. Chromium then returns an empty overflowX value for the removed element. The probe fails open, the sidebar opens, and native horizontal scroll stops.

I reproduced this in the mobile app. I removed a CSS-class scroll region after touchstart. The probe made zero scrollWidth reads, and the sidebar opened on touchmove.

Please check !session.startTarget.isConnected, clear the session, and return before preventDefault. Add touch and pointer tests that replace the scroll region before horizontal intent.

[SawyerHood]

Fixed in a1615d5 — the deferred probe now cancels the swipe when the start target is no longer connected, with a regression test covering the detach case.

[SawyerHood]

🚨 slopcop/review — Require exactly one deferred probe.

toBeGreaterThan(0) accepts a regression that probes on every move. The intended touch and pointer limit is one probe per gesture. Please use toBe(1) and apply the same bound to pointer coverage.

[SawyerHood]

Fixed in a1615d5 — the touch and pointer tests both assert exactly one probe per gesture (toBe(1)), including a second move event to catch per-move probing.

[SawyerHood]

🚨 SLOP COP 🚨 · review

ELI5 summary

The app used to inspect page layout on every mobile tap. This change waits until a person swipes.

The main fix works. However, a live message update can remove the original scroll target during a swipe.

The app can then open the sidebar instead of letting the person scroll code.

Findings

1. P2 — Fix the removed-target race before merge. A live render can disconnect startTarget before horizontal intent. Chromium then reports no computed overflow. The guard fails open and captures native horizontal scroll. I reproduced this in the mobile app. Fail closed when the target is not connected, then add touch and pointer regression tests.

2. P3 — Make the probe-count test exact. toBeGreaterThan(0) allows many layout probes. Use toBe(1) to protect the one-probe limit.

Other review results

The security review found no issue. The architecture scan found no duplicate code that this pull request must refactor.

The wheel path can still probe once per horizontal wheel event. That cost existed before this change. This change removes the cost from vertical wheel events.

A later change can mark horizontal overflow with an observer-backed attribute. The sidebar could then use closest() without a layout read.

Validation

• The focused sidebar tests passed: 5 of 5.
• The @bb/app typecheck passed through Turbo.
• A mobile Chromium test used a 390 by 844 viewport.
• Tap starts caused zero scrollWidth reads.
• A connected scroll region kept native horizontal scroll.
• Normal prose opened the sidebar.
• A removed scroll region reproduced the race.

I posted this as a comment-only review. I did not approve the pull request or request changes.