[matt2e]

What

Test-only. Fixes an intermittent Chromium failure in tests/browser/bestie-conversation.spec.mjs:165, "Bestie stays within a block host with multiline history at narrow widths". expect(getByRole('textbox', { name: 'Reply to thread' })).toBeInViewport() failed with "element(s) not found" because no thread had opened. It failed on run 42133368195 (#2419) and on an unrelated branch's run 42133084134, both in Browser journeys chromium 7/9.

Why it failed

With ?long at 480 px, the timeline opens at its latest message. The first "View thread: 1 reply" button starts out of view (viewport ratio 0), so locator.click() scrolled the timeline to reach it. After every scroll event, Virtua sets pointer-events: none on the list for 150 ms. Playwright hit-tested the button and pressed it. Under CPU load, React committed Virtua's scrolling style before the release. The release then reached the history <section>, and click went to the section. Playwright checks only the first pointer event, so click() reported success and the next assertion timed out.

• In both CI traces, the snapshot at the click's input has no pointer-events style on the list, and the snapshot after the click has pointer-events: none.
• Reproduced locally with event logging. Every logged failure showed the same sequence: pointerdown on the button, the list's style changes, then pointerup and click on the history section. Meanwhile the button stays connected at the same position, and elementFromPoint returns the section. The thread handler is never called.

This is the race #2560 diagnosed for the channel timeline.

Change

The test now opens the latest message's thread with clickRow from tests/browser/timeline.mjs. clickRow waits for Virtua to restore pointer events and for the geometry to settle. Then it requires the control to be fully in view and clicks without scrolling. The first button can't be used with clickRow because it is out of view when the conversation opens. Which thread opens doesn't matter to this test: every ?long root has the same multiline body, and the assertions cover the block host, the dock and the reply box.

Validation

Chromium with --repeat-each, 4 workers pinned to 2 cores (taskset) under an 8-CPU quota. The two runs ran side by side:

	Runs	Lost click (this failure)	page.goto 15 s timeout	Passed
main	200	2	12	186
this change	200	0	5	195

The page.goto timeouts are noise from this setup: cold Vite servers on overloaded cores. Across all loaded runs, the old click lost the click 6 times in 380 runs; this approach lost it 0 times in 324. Without load, main passed 60 of 60, and CDP CPU throttling did not reproduce it either.

• The whole Bestie spec passed 90 of 90 on Chromium and Linux WebKit (5 repeats).
• biome check and git diff --check pass.

Not addressed: as #2560 notes, clickRow can't stop an app scroll that starts after its idle wait.

🤖 Generated with Claude Code

[kazemek21]

I reviewed the PR and went through the Nexus review-tracker notes. I did not see any issues requiring comments.

Posted by Codex (gpt-6.1-sol) on behalf of kylez