iOS selector click can still tap a stale point after layout shifts the post-open settle does not cover
Maintainer thường phản hồi trong vòng 1 ngày
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
- 10/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
Hướng nghiên cứu
Start with the selector click path and the post-open settle from #3356, then read src/daemon/interaction-surface-signature.ts, which cannot track target identity across reads. The issue asks for evidence of the shift cases before any design, so first capture a fixture where the target moves between the click's capture and its tap. Done means the click either taps the new location or fails with a typed reason declared in the error taxonomy, with TAP_OUTCOME_NOT_OBSERVED_GAP in packages/contracts/src/interaction-guarantees.ts updated and warm-click p50 on 01-settings.ad unchanged.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Purpose
#3356 settles the next screen read after an iOS open that returns timing.postOpenObservation: "unobservable". Three cases from #3354 are still open. In each one a selector click can tap a stale point and report success:
- The layout moves between the click's own pre-tap capture and its tap, at any time and not only after an open.
- The layout moves after an
observableopen.observablemeans the tree was readable, not that it was at rest. - The post-open read never settles. The click gets
postGestureOutcome: unsettledand a warning, then taps anyway.
Evidence
The evidence is the same as #3354: main run 37815426076, where General was at y=319 and the settled list had it at y=406. Nobody has reproduced the shift locally. In 5 live runs of 01-settings.ad on an iOS 27.0 simulator, every read settled before the tap. Collect evidence that these cases happen before choosing a design.
Required behavior
- When the target's position can't be confirmed at dispatch, the click fails with a typed reason instead of tapping the old point. Declare the reason and its
detailsshape in the error taxonomy. - Judging that "the target moved" requires the target's identity across reads. The whole-surface signature comparison (
src/daemon/interaction-surface-signature.ts) can't establish it, and it collapses duplicate identities. - Do not add a capture or runner query to warm clicks whose layout is already stable.
- Give any bounded wait a wall-clock deadline, not only a polling budget. Capture cancellation must propagate: abort the capture and wait for it to stop, rather than racing a timer. Today the post-open loop's 1.5 s is a polling budget, and its two reads took 2.55–2.57 s live.
- A screen that animates constantly must not make a stable target unclickable.
- Update
TAP_OUTCOME_NOT_OBSERVED_GAPinpackages/contracts/src/interaction-guarantees.ts.
Completion
- A fixture where the target moves between the click's capture and its tap. The click either taps the new location or fails with the typed reason.
- Warm-click p50 on
01-settings.ad, measured before and after the change, does not regress. It was about 1.3 s on the iOS 27.0 simulator.
Rejected so far
- A runner-side frame check on every click. It would take an estimated 550–800 lines and add a query to every warm click.
- Settling after every iOS open. The first click would cost about 1.8 s more, with no evidence that
observableopens shift, and it still wouldn't cover shifts at other times. - Failing whenever the settle times out. A stable target next to an unrelated animation would be refused.
Related: #3354, #3356, #3335.
- Ngôn ngữ chính
- TypeScript
- Star
- 5.2k
- Fork
- 359
- Merge trung bình
- 13 giờ 23 phút
- Pull request đã merge (30 ngày)
- 655
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của callstack/agent-device
-
iOS alert wait: the last poll can get ~30 ms and turns "no alert" into a failed readCó thể đã có người làm @pcbeingused333 đã nhận 3 ngày trước. Đang mởbug ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
callstack/agent-device#4018 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
callstack/agent-device#1869 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-triage
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 5/100
callstack/agent-device#4205 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
callstack/agent-device#4204 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
callstack/agent-device#4203 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của callstack/agent-device
Issue tương tự
-
needs investigation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Makefile names visualizer gate targets that do not exist; the TS packages have no test runnerĐang mởarea:visualizer tech-debt
Độ khó 2/5 Dưới một giờ Mức phù hợp với người mới 66/100
jmbarzee/temporal-architect#292 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
riverqueue/river#1576 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
colbymchenry/codegraph#3228 ·
Maintainer thường phản hồi trong vòng 1 ngày