role= selector vocabulary diverges from snapshot kind
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- testing
Línea de trabajo
Read packages/kernel/src/snapshot.ts and the selector paths in packages/selectors/src/internal/match.ts and find.ts first. Decide the compatibility approach before changing behavior; if a cutover is chosen, update the selectors, the snapshot and client API documentation, and affected recorded-selector fixtures. Done means the rollout decision is documented and role= behavior and vocabulary are consistent with kind.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Context
#2656 added kind: string to structured snapshot nodes — the presenter's platform-neutral role vocabulary (button, text-field, text, switch, ...), computed by formatRole in packages/kernel/src/snapshot.ts and shared by every backend/projection.
Adversarial review of #2656 found that role= selector matching does not use that same vocabulary today, so the two completion conditions below cannot be satisfied without a separate, behavior-changing migration:
packages/selectors/src/internal/match.ts(roleselector term) andpackages/selectors/src/internal/find.ts(find role=...locator) each normalizenode.typeby strippingXCUIElementType/leaf-segment prefixes and lowercasing — producing raw leaf class names (statictext,edittext,textfield) rather thanformatRole's coarse vocabulary (text,text-field).packages/provider-webdriver/src/webdriver-source.ts(roleFromWebDriverType) independently falls back to a similarly-stripped type name when WebDriver'sclassattribute is absent, to populate the (iOS AX-derived)rolefield — a different field thankind, but the same kind of ad hoc normalization.packages/contracts/src/snapshot-text.ts(normalizeType) strips the same prefixes for a different purpose (fillable-type/keyboard-occlusion detection), so it is a distinct concern from role classification but shares the pattern.
Why this is its own issue, not folded into #2656
role= selector matching is a released, public selector feature (shipped before 0.21.x). Switching it to formatRole's vocabulary would change matching results for existing selectors and recorded scripts (e.g. role=statictext and role=edittext would stop matching; role=text/role=text-field would start). That is a breaking change to a versioned surface and needs an explicit compatibility/rollout decision (hard fail vs. an aliasing period), which is out of scope for a PR whose job is adding the kind field.
Proposed work
- Decide whether
role=(both the main selector term and thefindlocator) should match againstformatRole(node.type)instead of raw leaf-class normalization, and whether that is a hard cutover or needs a deprecation window. - If cutover: update
packages/selectors/src/internal/match.tsandpackages/selectors/src/internal/find.tsto import and useformatRolefrom@agent-device/kernel/snapshot, delete the now-redundantnormalizeRoleinfind.ts, updatewebsite/docs/docs/snapshots.mdandwebsite/docs/docs/client-api.mdto state role= shares kind's vocabulary, and sweep recorded-selector/doc fixtures that assume the old raw vocabulary. - Leave
packages/contracts/src/snapshot-text.ts#normalizeType(fillable/occlusion detection) andpackages/provider-webdriver/src/webdriver-source.ts#roleFromWebDriverType(the iOSrolefield fallback) alone unless the decision above says otherwise — they serve different fields/purposes thankind.
References
- #2656
- Lenguaje dominante
- TypeScript
- Estrellas
- 4.7k
- Forks
- 304
- Merge medio
- 11 h 25 min
- PR fusionados (30 d)
- 545
Preparar el entorno
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 callstack/agent-device
-
ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
callstack/agent-device#2995 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
callstack/agent-device#1869 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 75/100
callstack/agent-device#3047 ·
Los mantenedores suelen responder en 1 día
-
ready-for-agent
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
callstack/agent-device#3004 ·
Los mantenedores suelen responder en 1 día
-
Maestro `eraseText` fails on real Android devices: `test` and `replay` cannot opt in to the test IMEAbiertoready-for-agent
Dificultad 3/5 1-2 días Aptitud para principiantes 74/100
callstack/agent-device#2997 ·
Los mantenedores suelen responder en 1 día
Todos los issues de callstack/agent-device
Issues similares
-
priority: P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
prime-radiant-inc/evener#3291 ·
Los mantenedores suelen responder en 1 día
-
accessibility bug revealjs
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
quarto-dev/quarto-cli#14961 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
supabase/agent-skills#614 ·
-
Content
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
RunestoneInteractive/rs#1559 · 1 comentario ·
Los mantenedores suelen responder en 2 días