Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#184 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
playwright, typescript
領域
accessibility, testing-qa

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
0
フォーク
0
平均マージ
2時間 48分
マージ済み PR（30日）
8

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

usabl-dev/usabl のほかの issue

usabl-dev/usabl の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。