Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#184 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
playwright, typescript
Ambito
accessibility, testing-qa

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
0
Fork
0
Merge medio
2h 17m
PR unite (30g)
10

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di usabl-dev/usabl

Tutte le issue di usabl-dev/usabl

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.