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

An inspect screenshot can be stale for point clicks when its AX walk grows the layout

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

Maintainer thường phản hồi trong vòng 1 ngày

Một pull request liên quan đã được merge.

  • #221 của @iamnbutler — đã merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/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ệ
swift
Lĩnh vực
accessibility, desktop

Hướng nghiên cứu

Start at the desktop_inspect accessibility flow and trace how it captures a screenshot before walking the window's Accessibility tree; the issue names no source files or tests. Reproduce in System Settings > Spotlight by comparing the initial screenshot with element frames and a mode: pixels capture after the walk. Done when the inspect result's screenshot and point-click coordinates remain aligned despite rows loading during the AX walk.

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

Mô tả

desktop_inspect captures the screenshot first, then walks the window's Accessibility tree. Some SwiftUI lists load rows as their children are read and get taller. So the walk can move content after the screenshot is taken, and a point read off that screenshot no longer lands on what it showed.

Repro (System Settings > Spotlight, macOS 27)

  1. Open x-apple.systempreferences:com.apple.Spotlight-Settings.extension and scroll the content to the bottom, so Search Privacy… is visible.
  2. desktop_inspect (accessibility mode). The screenshot shows Search Privacy… at about y=709 (global). Immediately afterwards a raw AX read gives its frame as y=757, and a mode: pixels capture shows the content has moved down by the same amount.
  3. A point click at the screenshot's position now targets whatever moved under it. Here that's the disabled Clear Clipboard History button, not Search Privacy….

Every full walk grows the "Results from Apps" list again: I saw 40–136 pt drifts across runs. The list shrinks back after a while, so the drift depends on timing.

Workaround

Take a mode: pixels snapshot just before the point click. It doesn't walk the tree, so its screenshot matches the layout the click sees. The #147 live check used this: AX inspect, element scroll, pixels snapshot, then a point click.

Related

#147 (fixed in #157) was the same mechanism inside the click: its own descendant walk moved the button off the point. The click now expands only elements whose frame contains the point. Inspect still walks the whole window, and the 200-element listing needs that walk.

Possible directions

  • Read frames back after the walk, and flag or refuse when they moved relative to the capture.
  • Capture the screenshot after the walk, or re-capture when the walk changed the frames of elements it had already read.
  • Have the point click compare its hit-test result against the snapshot's element at that point.
Ngôn ngữ chính
Swift
Star
0
Fork
0
Merge trung bình
39 phút
Pull request đã merge (30 ngày)
162

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 githubnext/desktop-tools

Tất cả issue của githubnext/desktop-tools

Issue tương tự

Thêm issue về Swift

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.