An inspect screenshot can be stale for point clicks when its AX walk grows the layout
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 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
- 平均マージ
- 42分
- マージ済み PR（30日）
- 123
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
githubnext/desktop-tools のほかの issue
-
ace documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
githubnext/desktop-tools#104 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
githubnext/desktop-tools#143 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
githubnext/desktop-tools#129 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 8/100
githubnext/desktop-tools#5 · コメント 11 件 ·
メンテナーはふだん 1 日以内に返信
-
ace
難易度 5/5 1週間以上 初心者へのやさしさ 6/100
githubnext/desktop-tools#4 · コメント 16 件 ·
メンテナーはふだん 1 日以内に返信
githubnext/desktop-tools の issue をすべて見る
似ている issue
-
area/kotlin
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
cable-report
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
darrylmorley/whatcable#656 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
omlahore/RemoveMacAI#67 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
521xueweihan/HelloGitHub#4049 ·
-
enhancement UI
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信