Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#184 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tài liệu
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
playwright, typescript
Lĩnh vực
accessibility, testing-qa

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
0
Fork
0
Merge trung bình
2 giờ 48 phút
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của usabl-dev/usabl

Tất cả issue của usabl-dev/usabl

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.