[matt2e]

Problem

thread-resize.spec.mjs:99 "thread preserves bottom and reading position through activity and composer resizing" fails on Linux WebKit at line 292: the reading check after activity above the reader ends (Expected: < 4, Received: 16). It started after #1729 merged (6565eea) and failed on four unrelated branches within two hours: tho/solo-share-view-only, fix/solo-access-journey-budget, kalvin/managed-nsec-backup-consent and user-statuss-dont-show-emoji-name-on-hover (#2384). Main's own runs at the same commits passed.

Cause

ThreadPanel keeps the reader in place by correcting each resize in its ResizeObserver. That observer runs only in a rendering update, and on a loaded Linux WebKit runner those are far apart. settle() can then see geometry rest while a correction is still pending.

The CI trace shows the sequence. When activity starts, scrollTop moves 956 → 1032 (+76). When it stops, it moves only 1032 → 972 (−60). The leave animation stops at the section's 16 px padding floor (0fr can't collapse the child's padding), and the section stays mounted until the animation ends. Leaving also sets aria-hidden at once, so the test's getByRole("region")…toHaveCount(0) passed about 60 ms after turn_completed. The section's removal is the last resize, and the check ran before the correction for it. Arrival can fail the same way (line 281), and so can the bottom check after the composer grows (line 193).

The product corrects in the same rendering update as the layout change, before paint, so users don't see a jump. Only the test's timing changes.

Change

Only tests/browser/thread-resize.spec.mjs changes:

• settled(): wait two rendering updates with the existing frames() helper, then settle(). Every settle in this test uses it.
• arrived(row): wait for the activity section's own animations to finish, as ActivityAccessory does before it unmounts the section.
• left(row): wait for [data-message-activity] to leave the DOM, not just the accessibility tree.

The shared settle() helper is unchanged. Browser cases added or removed: none.

Validation

All runs use the Playwright v1.63.0-noble container (Linux WebKit, as in CI) with playwright.ci.config.mjs --no-deps and 4 workers. "Loaded" means all 16 container CPUs were busy.

Variant	Result
Original, loaded	9/12 failed (8 at :292, as in CI)
Only reading checks fixed, loaded	5/24 failed at :193 (Received: 168)
This PR, loaded	24/24 passed
This PR, full file, unloaded (both engines, 3 repeats)	36/36 passed
This PR, macOS (both engines)	8/8 passed

Instrumenting ThreadPanel showed the correction for the removal landing after the test's check. Logging that read geometry inside the observer callback hid the race (0/12 failures), which points to rendering-update timing, not to the correction logic.

🤖 Generated with Claude Code