Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix(test): make canvas breakpoint-frame tests wait on readiness instead of fixed sleeps #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
fix(test): make canvas breakpoint-frame tests wait on readiness instead of fixed sleeps #57
Changes from all commits
b59b8ffFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
The canvas-breakpoint tests flaked in CI (Verify step of the release workflow), failing reliably on a loaded runner while passing locally. Root cause: the canvas reveals breakpoint frames progressively (useProgressiveCanvasFrameLoading — the active frame after a requestAnimationFrame, each inactive frame behind a chained setTimeout(32ms) → requestIdleCallback({timeout:160ms})), then mounts each frame's iframe and portals the page tree in. The failing tests all query the `mobile` frame, which — with `desktop` active — is the FIRST inactive frame, so it appears only after that whole async chain. The tests waited with fixed budgets: a hardcoded setTimeout(90ms) "flush" and the default 1000ms waitFor. Those are calibrated for a fast laptop; under CI event-loop saturation the timers drift past both, so the iframe content isn't present when the assertion runs. Proven by inflating the reveal delay to 1500ms locally, which reproduced the exact CI signature (activation tests timing out ~1010ms, rendering tests failing ~110ms); with this change the same simulation passes 17/17. Fix: replace every arbitrary sleep with condition-based waiting. Add shared waitForCanvasFrameDocument / waitForCanvasNodeInFrame / waitForCanvasElement helpers in iframeCanvasQuery.ts that poll the real readiness condition with a CI-tolerant 5s ceiling (waitFor returns the instant the condition holds, so zero cost on a fast machine). This also removes the flushProgressiveCanvasFrames helper that was copy-pasted across four test files. Product code is untouched — the progressive loader is correct; the tests were making brittle timing assumptions. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
Uh oh!
There was an error while loading. Please reload this page.