iOS 26: `_UIFloatingBarContainerView` marks sheet content (and sometimes whole screens) as covered
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- swift, typescript
Hướng nghiên cứu
Start with the coverage pass that marks toolbar nodes as overlays, and the full-window exemption it applies, then check how snapshot -i filters window nodes before that exemption runs. Reproduce with a SwiftUI sheet containing a List of Buttons on an iOS 26 simulator, comparing snapshot --raw --json with press. Done when rows in a sheet are pressable by ref, label and identifier, and snapshot -i agrees with what press decides.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Environment
- agent-device 0.21.19
- iOS 27.0 simulator (iPhone, 402×874 pt); the floating bar container exists since iOS 26
- SwiftUI app with a
NavigationStackand a.sheetwith.presentationDetents([.medium, .large])
Summary
On iOS 26, UIKit adds a floating bar container (_UIFloatingBarContainerView) to every navigation context. XCUITest reports it with type Toolbar and label Toolbar. agent-device's coverage pass treats every toolbar node as an overlay. The full-window exemption only applies when the bar's rect equals the nearest window rect.
So:
- In a sheet the container has the sheet's frame (for example
x8 y415 w386 h451), not the window frame. It comes later in tree order than the sheet rows, so every row is markedcovered.press @ref,press 'label="…"', andpress 'id="…"'all fail withcovered by another visible element. The rows are hittable in the app; a coordinate tap at their centre works. - On a full-screen view the container has the window frame and is exempt in the full snapshot. In
snapshot -ithe window node is filtered out, so the exemption cannot apply, and every node prints[covered]even though presses work.
The container has no interactive children of its own in these cases.
Steps to reproduce
- Present a SwiftUI sheet containing a
ListofButtonrows on an iOS 26 simulator. agent-device snapshot -i→ all rows[covered].agent-device press 'id="<row identifier>"'→covered by another visible element.agent-device snapshot --raw --jsonshows aToolbarnode (_UIFloatingBarContainerView) after the rows, with the sheet's rect.agent-device press <centre x> <centre y>→ the row activates.
Expected
Rows inside the sheet are pressable by ref, label, and identifier.
Suggested fix
Any one of:
- Do not treat
_UIFloatingBarContainerView(or atoolbarwith no interactive descendants) as an overlay. - Exempt a bar whose rect equals its nearest sheet/scene container rect, not only the window.
- Apply the full-window exemption before
-ifiltering, sosnapshot -imatches whatpressdecides.
Related (separate issue?)
A SwiftUI Menu prints as [popupbutton] with an unlabeled child [button] that nearly fills it. press on the popup button fails with has no parent-owned touch point outside its interactive descendants, because no point is ≥12 pt from the child. Treating a child whose rect is within a few points of the parent as the same target (or pressing the child automatically when it is the only competitor) would make SwiftUI menus pressable by label or identifier.
- Ngôn ngữ chính
- TypeScript
- Star
- 5k
- Fork
- 334
- Merge trung bình
- 12 giờ 29 phút
- Pull request đã merge (30 ngày)
- 663
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
-
`devices` reports a phantom Android emulator named after the emulator's crashdata INFO bannerCó thể đã có người làm @airowe đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
callstack/agent-device#3716 ·
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
-
backlog refactor
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 8/100
callstack/agent-device#3759 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backlog enhancement needs-triage
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 8/100
callstack/agent-device#3758 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement ready-for-agent
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
callstack/agent-device#3757 ·
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ự
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
lingdojo/kana-dojo#32590 · 1 bình luận · 5 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug p2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
bastani-inc/atomic#3703 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backend bug difficulty: medium priority: medium reliability
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
trustflow-protocol/trustflow-backend#730 ·
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 74/100
firecrawl/firecrawl-mcp-server#548 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày