Skip to content

Wait for a fragment link's target to open in the browser test - #685

Merged
JacobStephens2 merged 1 commit into
mainfrom
failing-ci
Oct 14, 2026
Merged

JacobStephens2 merged 1 commit into
mainfrom
failing-ci

Conversation

@JacobStephens2

Copy link
Copy Markdown
Owner

Summary

site-test has failed on main since #684. The fragment-link test checks visibility right after clicking CREDITS.md, but the page opens the folds on hashchange. On GitHub's runners that event always arrived after Playwright's click returned.

 click a[href="#file-thirdshift-pr-credits-md"]
-assert credits.isVisible() === true      // snapshot, races hashchange
+await credits.waitFor({ state: "visible", timeout: 5000 })

The repeated-link check further down stays a snapshot: that path reveals synchronously in the click listener.

Evidence

  • Before: site-test red on main and on all three attempts of Fold Prompts and skills sections by default #684's run, each time with false !== true at prompts.test.cjs:87. Locally, delaying the page's hashchange handler by 50 ms reproduces the same assertion failure.
    After: the same 50 ms delay passes, and npm test --prefix site passes 3/3 locally. This PR's own site-test run is the CI check.

Merge Danger

Door: two-way

Test-only change.

Blast Radius: site-test

🤖 Generated with Claude Code

The page reveals a newly linked fragment on hashchange, which Chrome can
deliver after Playwright's click returns. On GitHub's runners it always
did, so the immediate isVisible() check failed site-test on main.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant