fix(e2e): round 12 — handleReAuthModal retries when modal re-appears (WebKit Argon2id flake)

[TortoiseWolfe]

Summary

• Failure screenshot from PR feat: #48 Three.js Game at /game/3d (047 — full SpecKit cascade) #95 rebased run 26105491210/webkit-msg reveals the test is stuck on the ReAuthModal, not on a scroll bug.
• Round-10 fix (concurrency mutex) and round-11 fix (PR fix(scroll): round 11 — MessageThread native scroll listener (WebKit E2E flake) #97 native scroll listener) both remain correct — they applied to different surfaces.
• This is a separate, deeper flake in handleReAuthModal: Playwright's waitFor({state:'hidden'}) resolves on a brief transition during Argon2id processing, the helper returns true, then the modal re-appears when the actual unlock fails.

Failure evidence

Failure-time screenshot extracted from blob-report-webkit-msg-0/extracted/resources/796501bc4e45158f1f22d5cfe0e35fb574710a9d.png:

Page shows "Enter Your Messaging Password" modal with scripthammer.e2e+test-primary@gmail.com pre-filled. No message thread, no conversation list, no scroll surface. The [data-testid="jump-to-bottom"] button was never going to exist.

The trace shows Wait for selector locator('[role="dialog"]').first() (state=hidden) succeeding, the test proceeding to viewport setup, navigation, clickFirstConversation, scroll setup, and assertion — but the failure screenshot shows the modal back. The helper trusted a brief hidden transition that didn't stick.

Root cause

1. Test fills password, clicks Unlock Messages
2. ReAuthModal starts Argon2id derivation (slow on WebKit/Linux/CI)
3. Modal briefly transitions hidden during processing
4. Playwright.waitFor({state:'hidden'}) resolves on this transition
5. Helper returns true — but unlock actually fails internally
6. Modal re-opens
7. Test continues into a UI that never mounted

WebKit-specific because WebKit's WebCrypto thread contention on Linux runners is significantly worse than chromium/firefox.

Fix

After waitFor({state:'hidden'}) resolves, verify hidden state is sustained for ~2 seconds via a sleep+recheck. If the modal pops back, treat as transient failure and retry the password unlock up to 3 times total.

const MAX_ATTEMPTS = 3;
for (let attempt = 1; attempt <= MAX_ATTEMPTS; attempt += 1) {
  // ...fill + click + waitFor(hidden, 90s)...
  const sustainedHidden = await modal
    .waitFor({ state: 'hidden', timeout: 2000 })
    .then(async () => {
      await new Promise(resolve => setTimeout(resolve, 2000));
      return (await modal.count()) === 0 || !(await modal.isVisible());
    })
    .catch(() => false);
  if (sustainedHidden) return true;
  // else loop
}
return false;

Why this is structural, not a band-aid

• The waitFor API resolves on transition events; we now confirm steady-state. Same pattern React 18+ ecosystem applies for useTransition-style state where intermediate values can fire listeners.
• 3 retries is bounded — no infinite loops.
• Returns false cleanly if all attempts fail; callers can branch.
• No timeout extensions beyond the existing 90s per attempt.
• Doesn't mask other test bugs: if the unlock genuinely fails 3x, the test gets a definitive failure (instead of a confusing downstream error like "button not found").

Test plan

• Type-check clean
• Lint clean
• CI passes (this PR)
• After merge, PR feat: #48 Three.js Game at /game/3d (047 — full SpecKit cascade) #95 rebases onto new main and passes webkit-msg

Rounds 10 / 11 / 12 — independent, all correct

Round	Fix	Layer
10 (#89)	repo-wide E2E concurrency mutex	CI serialization vs Supabase races
11 (#97)	MessageThread native scroll listener	React onScroll synthetic event vs WebKit dispatch
12 (this)	handleReAuthModal sustained-hidden verification	Playwright waitFor transition vs sustained DOM state

Each addresses a distinct flake mode. Round 12 was previously masked because rounds 10 and 11 weren't fully closed yet, so other shards failed first.

🤖 Generated with Claude Code