An inspect screenshot can be stale for point clicks when its AX walk grows the layout
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 48/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- swift
- 領域
- accessibility, desktop
研究方向
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.
由索引模型根據 Issue 內容生成。
描述
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)
- Open
x-apple.systempreferences:com.apple.Spotlight-Settings.extensionand scroll the content to the bottom, so Search Privacy… is visible. 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 amode: pixelscapture shows the content has moved down by the same amount.- 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.
- 主要語言
- Swift
- 星號
- 0
- 分支
- 0
- 平均合併
- 39 分鐘
- 30 天內合併 PR
- 144
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
githubnext/desktop-tools 的其他 Issue
-
ace documentation
難度 2/5 1-3 小時 新手友好度 79/100
githubnext/desktop-tools#104 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 48/100
githubnext/desktop-tools#179 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 48/100
githubnext/desktop-tools#178 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 48/100
githubnext/desktop-tools#177 ·
維護者通常 1 天內回覆
-
難度 3/5 1-2 天 新手友好度 67/100
githubnext/desktop-tools#176 ·
維護者通常 1 天內回覆
查看 githubnext/desktop-tools 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 82/100
維護者通常 1 天內回覆
-
storage: remove unused BucketName wrapper aliases可能已有人在做 @chingor13 今天認領。 未關閉api: storage type: cleanup
難度 2/5 1-3 小時 新手友好度 83/100
googleapis/google-cloud-swift#1509 ·
維護者通常 1 天內回覆
-
📦 expo-updates contributor: external iOS needs review sdk-57 sdk-58 severity: medium
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
bug good first issue help wanted
難度 2/5 1-3 小時 新手友好度 63/100
marcovisona/arca#5 ·
-
enhancement good first issue
難度 2/5 1-3 小時 新手友好度 78/100
luis-guillen/airy#2 ·