iOS 26: `_UIFloatingBarContainerView` marks sheet content (and sometimes whole screens) as covered
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Bug
- Clareza
- Claramente especificada
- Status de atividade
- Ativa
- Stack de tecnologia
- swift, typescript
Direção de pesquisa
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.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- TypeScript
- Estrelas
- 5k
- Forks
- 334
- Merge médio
- 12h 29min
- PRs com merge (30d)
- 663
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de callstack/agent-device
-
bug ready-for-agent
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
callstack/agent-device#3627 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
callstack/agent-device#1869 ·
Mantenedores costumam responder em até 1 dia
-
A session lost to a daemon takeover ("Replacing daemon … unreachable") answers the next request with AMBIGUOUS_MATCH when two simulators are bootedTalvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Abertabug ready-for-agent
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 25/100
callstack/agent-device#3674 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
enhancement ready-for-agent
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
callstack/agent-device#3531 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
iOS: an Xcode too old for the host macOS surfaces as 'Runner did not accept connection'Talvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Aberta
Dificuldade 4/5 1-2 dias Facilidade para iniciantes 55/100
callstack/agent-device#3449 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
Todas as issues de callstack/agent-device
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
Mantenedores costumam responder em até 1 dia
-
bug category:ai category:devices effort:s
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
LanternOps/breeze#8943 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
-
area:reliability difficulty:easy help wanted points:100 Stellar Wave
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 80/100
Divinity-Labs/Lens#341 · 1 comentário ·
Mantenedores costumam responder em até 1 dia