Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#184 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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 分钟
30 天内合并 PR
8

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

usabl-dev/usabl 的其他 Issue

查看 usabl-dev/usabl 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。