Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Readiness residual: a client-side pause longer than the DOM window is graded on the pre-mount DOM

Open
  • Is something wrong?
#184 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
playwright, typescript
Domain
accessibility, testing-qa

Research direction

This issue records an accepted readiness limitation from #146, measured against real Chromium; it does not name a file or test. Read the #146 readiness fix and its security review to understand the DOM stability and network quiet windows. The stated outcome is a disclosure that explains the late-fetch false green and why increasing readyTimeoutMs does not address it; the issue leaves any broader fix as a tradeoff.

Written by the indexing model from the issue text.

Description

area: engine bug

What this is

An accepted, documented residual of the #146 readiness fix, filed so it is visible rather than
living only in a code comment. It is invariant-5 surface (a false green), and it is inherent to
the design's refusal to require application cooperation, so it is tracked, not silenced.

The residual

waitForRendered returns when the DOM has been stable for the settle window and the network has
been quiet for the quiet window at the same time. A page that mounts a small stable DOM, goes
fully idle (no request in flight, DOM frozen) for longer than the settle window, then fires a
late fetch that mounts the real content, satisfies both conditions during the frozen gap and is
graded on the small DOM.

Measured against real Chromium

frozen gap 1500ms: waited 5055ms, saw 40 controls   caught
frozen gap 1800ms: waited 1688ms, saw 0             FALSE GREEN
frozen gap 2100ms: waited 1660ms, saw 0             FALSE GREEN
frozen gap 4000ms: waited 1906ms, saw 0             FALSE GREEN

The threshold is about 1700ms of frozen idle, which is the roughly 1500ms DOM stability window
plus margin. Past it, readiness returns having seen none of the content the page mounts later.

Why it is not fixed in #146

The signal that would catch it, a request in flight, is genuinely absent during a pure
client-side pause, so both the DOM-stable and network-quiet conditions are truly met. Closing it
needs either the application to signal its own render completion, which the design deliberately
refuses so it can measure any app without cooperation, or a larger DOM stability window, which
taxes every settled page and only moves the threshold. #146 explicitly rejected widening the
window for that reason.

An operator cannot work around it with readyTimeoutMs: a bigger budget does not help, because
the loop already believes it is done. That should be stated in the disclosure so nobody is
misled.

Scale, honestly

This is a large reduction from the pre-#146 exposure, not a new hole. Before #146 the readiness
check trusted a one-shot networkidle event and returned on the initial empty document for
essentially every client-rendered app. #146 shrank that to "an app with a client-side pause
longer than ~1.7s with no request behind it." The residual is what is left after that.

Fix direction, if it is ever worth the cost

A larger or adaptive DOM stability window trades the residual for a slower scan on every page.
An application-cooperation signal (a ready marker the app sets) closes it fully but reintroduces
the per-application coupling the element-count heuristic exists to avoid. Neither is clearly
worth it; this issue exists to keep the tradeoff visible.

Origin

Found and quantified during the #146 security review against real Chromium. Accepted residual,
not a blocker for #146.

Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
2h 48m
Merged PRs (30d)
8

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from usabl-dev/usabl

All issues in usabl-dev/usabl

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.