Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#159 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
swift
Área
accessibility, desktop

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Swift
Estrellas
0
Forks
0
Merge medio
39 min
PR fusionados (30 d)
144

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de githubnext/desktop-tools

Todos los issues de githubnext/desktop-tools

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.