checkPage ignores a screen's declared readiness signal
Maintainers usually reply within 1 day
A pull request for this has already been merged.
- #335 by @eparenti — merged
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- playwright, typescript
- Domain
- accessibility, testing
Research direction
Start with src/surfaces/playwright-helper.ts and compare checkPage with the CLI readiness check for configured screens. Follow how screenId resolves to a screen and how reachedWhen is evaluated. Done when a missing readiness selector produces a coverage gap naming it and providers do not run; run the relevant Playwright helper tests.
Written by the indexing model from the issue text.
Description
What happens
checkPage (the Playwright helper, src/surfaces/playwright-helper.ts) runs the providers right away on the page it is given. It uses its own PAGE_CHECK_CONFIG, which holds no surfaces, so a screen's declared reachedWhen selector is never checked.
Why it matters
The CLI path makes a screen a not-covered gap when its declared selector does not appear. checkPage does not. If a test calls checkPage with a configured screenId while the page shows only its empty shell, the result can be verified. That result is advisory and does not reach the merge gate, but it still reads as a pass for content that was never on the page.
Expected
When the screenId names a configured screen that declares reachedWhen, checkPage applies the same readiness rule as the CLI. If the signal does not hold, the result is a coverage gap that names the selector, and no providers run.
Status
Found in review by reading the code. This is old behavior, not added by a recent change. Related: #304 (other checkPage input checks).
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 9h 27m
- Merged PRs (30d)
- 31
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from usabl-dev/usabl
-
area: setup bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area: engine enhancement performance
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
accessibility area: engine bug
Difficulty 4/5 3-5 days Newbie friendliness 59/100
Maintainers usually reply within 1 day
-
Scan browser runs without Chromium's sandboxPossibly taken A pull request linked to this issue is open or already merged. Openarea: engine security
Difficulty 4/5 3-5 days Newbie friendliness 46/100
Maintainers usually reply within 1 day
-
area: engine bug security
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
Similar issues
-
Parallel reticle_verify opens per-flow leases without the source lease's ignoreHTTPSErrorsPossibly taken @as992949791 claimed this today. Opengood first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
reticlehq/reticle#2033 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area:quality p3-medium ready-for-agent type:docs
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
fderuiter/deruiter.dev#3589 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
manfredsteyer/angular-oauth2-oidc#1514 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
marmelab/react-admin#11431 ·
Maintainers usually reply within 1 day