Define the scan observation contract before any keyboard walk optimization
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- playwright, typescript
- Área
- accessibility, testing-qa
Línea de trabajo
Read the transcript walk and keyboard walk provider code that implement the fixed 50 presses and accessibility node reads; the issue does not name their files or tests. First establish the observation contract for press count, node read timing, and page state, then re-baseline the findings and verdicts against it. Done means the walk-once change preserves that contract and matches the re-baselined behavior.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What
The transcript walk presses Tab a fixed 50 times and discards everything after the first repeated element path; the keyboard walk provider then walks the same focus order a second time and reads the accessibility node twice per stop.
Why the obvious fix was dropped
A branch that stopped the walk at the first cycle and read the node once produced identical transcripts but different findings and verdicts on real Chromium: the discarded presses fire focus and blur handlers that mutate the page (a button added after the third focus made the old walk a regression and the new walk verified, and the reverse also occurred), and a single read drafts from an earlier instant than the second read.
Direction
Write down the observation contract first: exactly how many presses, when the node is read, what page state the providers see. Then re-baseline against it and make the walk-once change under that contract. Measured saving: about 1 second on a small app, about 2.5 seconds on a large one, more with the duplicate read removed.
- Lenguaje dominante
- TypeScript
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 2 h 48 min
- PR fusionados (30 d)
- 8
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de usabl-dev/usabl
-
area: engine bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
Stop hook allows a stop on an unknown verdict, and the self-check prints IDLE for a null verdictAbiertoarea: assistants bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
area: engine bug security
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Overlay: browser context failures are counted per plugin, not per browser, and close is not sharedAbiertoarea: overlay bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
-
area: engine enhancement performance
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Todos los issues de usabl-dev/usabl
Issues similares
-
native
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
prime-radiant-inc/evener#4839 ·
Los mantenedores suelen responder en 1 día
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
processone/fluux-messenger#1790 ·
Los mantenedores suelen responder en 1 día
-
🛣️ Infrastructure
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
opencrvs/opencrvs-core#14232 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
kunchenguid/gh-axi#220 ·
Los mantenedores suelen responder en 1 día