role= selector vocabulary diverges from snapshot kind
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- testing
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- TypeScript
- Star
- 4.8k
- Fork
- 315
- Merge trung bình
- 11 giờ 25 phút
- Pull request đã merge (30 ngày)
- 545
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của callstack/agent-device
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
callstack/agent-device#3062 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
callstack/agent-device#2995 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
callstack/agent-device#1869 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 57/100
callstack/agent-device#3060 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Android test-IME fill commits into a stale InputConnection session after focus moves to a new fieldĐang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 74/100
callstack/agent-device#3052 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của callstack/agent-device
Issue tương tự
-
refactor
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 5 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
OHDSI/Data2Evidence#3450 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
e2e-failure ready-to-code
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
automation missing-model model-sync provider:ofox
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
anomalyco/models.dev#8421 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
SlackAdapter and TelegramAdapter are not assignable to Adapter under exactOptionalPropertyTypesĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày