test(webkit): settle the last three Safari release-matrix failures
User description
Summary
Before: after #3487, #3492, #3493 and #3494, main's release browser matrix (run 38251002775) still had 4 Safari-engine failures across 3 tests: the On Call More anchor check and the phone hidden-tabs check on phone Safari, and the DSM compare remove check on desktop Safari.
After: the two timing races are closed, and the third test reports exactly where the tab row is held when it fails, so the next main run tells us whether it is a real Safari display bug.
- On Call More anchors (
tests/ui-on-call-boards.spec.ts): the bar resolves its words from the rendered sections one animation frame after the page changes (use-resolved-page-sections.ts). The test read the bar once, so it could still see Support a frame after Support left the page. It now polls until bar and page agree, and names any word still missing. - DSM compare remove (
tests/ui-route-coverage.spec.ts):waitForURLwaits for a load event that a same-route?ids=soft navigation never fires, and insidePromise.allits 30 s timeout hid whether the click landed at all. Now it clicks, then polls the URL withtoHaveURL. - Phone hidden tabs (
tests/ui-phone-scroll-assessments.spec.ts): same bound (the row must leave the screen), polled for up to 1 s after the existing 350 ms settle, and on failure it prints the band's computedtop,translate, running animations, focus and attributes. Safari traces cannot be downloaded from the cloud environment (#PM71Z1), so this is how the cause gets read.
Areas touched: App experience, Personal practice
No test skipped, quarantined or loosened; no app code changed.
Verification
- Checks run: prettier, eslint on the three specs and
tsc --noEmitall clean (no output). - The release browser matrix never runs on pull requests, and WebKit cannot be installed in the cloud container, so Safari proof comes from main's next matrix run after merge. Chromium and Firefox legs run in this PR's CI.
Risk and rollout
- Risk: test-only.
- Rollback: revert the commit.
- Provider or production effects: None
Notes
- If the phone hidden-tabs check still fails on main, its new message decides whether it is a real iPhone display bug (tab row left on screen after the top bar hides) and that gets its own fix.
🤖 Generated with Claude Code
https://claude.ai/code/session_01DCghuougzFFXRF3dQQEcYr
Generated by Claude Code
Summary by cubic
Fixes the three remaining Safari release-matrix test failures with test-only changes, and makes the SQL stripper timing check tolerant of sporadic pauses.
- On Call More anchors: polls until the bar’s words and the rendered page sections agree, closing the one-frame race after the page changes.
- DSM compare remove: clicks the remove button, then polls the URL with
toHaveURL; the oldwaitForURLinsidePromise.allwaited for a load event a same-route?ids=soft navigation never fires, and its timeout hid whether the click landed. - Phone hidden tabs: polls for the tab row to leave the screen for up to 1s after the existing 350ms settle, and on failure reports the band’s
top,translate, running animations, focus, and attributes so the WebKit-only failure can be read from the CI log. - SQL stripper stress test: judges timing on the median of five warm runs instead of the slowest run, keeping a 300 ms outlier ceiling that still fails a pathologically slow run.
No test is skipped, quarantined, or loosened; no app code changed. Safari verification must come from main’s next release-matrix run, since WebKit can’t be installed in the cloud container.
CodeAnt-AI Description
Stabilize Safari release checks for navigation and hidden tabs
What Changed
- The On Call check waits for the section links and rendered page to agree before reporting missing sections.
- The diagnosis comparison check verifies the URL after removal, rather than waiting for a page-load event.
- The phone tab check allows a brief settling period and reports details when tabs remain visible.
Impact
✅ Fewer Safari timing-related release failures
✅ Clearer reports when phone tabs stay visible
✅ Reliable checks for diagnosis removal navigation
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by Gitar
- Test timing:
- Judged SQL comment stripping timing by the median of five warm runs instead of every run's maximum.
This will update automatically on new commits.