An inspect screenshot can be stale for point clicks when its AX walk grows the layout
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 48/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- swift
- Domaine
- accessibility, desktop
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Swift
- Étoiles
- 0
- Forks
- 0
- Merge moyen
- 39 min
- PR mergées (30 j)
- 144
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de githubnext/desktop-tools
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
githubnext/desktop-tools#192 ·
Les mainteneurs répondent en général sous 1 jour
-
Ace: adopt desktopToolRules()Ouverteace documentation
Difficulté 2/5 1-3 heures Accessibilité débutants 79/100
githubnext/desktop-tools#104 ·
Les mainteneurs répondent en général sous 1 jour
-
Status-item NSMenu (MenuBarExtra .menu): opens but can't be inspected via Accessibility or dismissedOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
githubnext/desktop-tools#193 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
githubnext/desktop-tools#191 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
githubnext/desktop-tools#179 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de githubnext/desktop-tools
Issues similaires
-
ci-failure ci:assertion test
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
openwatersio/slackwater-ios#811 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 63/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
foxglove/mcap#1907 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
good first issue help wanted translation
Difficulté 2/5 1-3 heures Accessibilité débutants 83/100
-
[Tool] AnnotatorOuvertehas-image has-license has-readme new-tool ready-to-approve repo-verified
Difficulté 1/5 Moins d'une heure Accessibilité débutants 78/100
shanselman/TinyToolTown#873 ·
Les mainteneurs répondent en général sous 5 jours