role= selector vocabulary diverges from snapshot kind
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 45/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- testing
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- TypeScript
- Stelle
- 4.8k
- Fork
- 315
- Merge medio
- 11h 25m
- PR unite (30g)
- 545
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di callstack/agent-device
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
callstack/agent-device#3062 ·
I maintainer di solito rispondono entro 1 giorno
-
ready-for-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
callstack/agent-device#2995 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
callstack/agent-device#1869 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 57/100
callstack/agent-device#3060 ·
I maintainer di solito rispondono entro 1 giorno
-
Android test-IME fill commits into a stale InputConnection session after focus moves to a new fieldAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 74/100
callstack/agent-device#3052 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di callstack/agent-device
Issue simili
-
needs:triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
ai-discovered
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
jessepollak/home#1627 ·
I maintainer di solito rispondono entro 1 giorno
-
agent-canvas bug llm priority:low ready-for-dev
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
OpenHands/OpenHands#17806 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
radius-project/ai-extensions#923 ·
I maintainer di solito rispondono entro 1 giorno