Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

It should not be an error for focus to point to a missing `NodeId`

Aberta
#587 4 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
28/100
Tipo de issue
Bug
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
rust
Domínio
accessibility

Direção de pesquisa

Comece rastreando o tratamento existente do AccessKit para o NodeId raiz e o NodeId com foco, especialmente a verificação de nós desconhecidos e o caminho Action::ScrollIntoView. Compare as alternativas propostas de fallback, suporte a nós desconhecidos e nós órfãos antes de escolher um comportamento. A tarefa estará concluída quando a ausência do destino do foco não causar mais uma falha indevida e o comportamento selecionado tiver cobertura.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

kas::Id is a (compressed) path, which allows tracking focus of unrealised (hidden) entries in a list while virtual scrolling. As such, it is not a bug for Kas's focus to point at a widget which doesn't exist. It is still possible to operate on such an Id by scrolling it back into view.

(No, Kas does not do this by keeping a copy of any widget in focus while scrolled out of view. It would be possible, but would require hacks in widget code, and imply that bugs in widget code can crash a UI when accessibility is enabled.)

Working around this

From the Kas side, I can check whether nav_focus points to a reachable widget (reverting to the root Id if not), but this is not equivalent to the AccessKit check since Kas may have dormant nodes not in the AccessKit tree. To accurately match the AccessKit check I'd need to store a copy of the tree.

The right way?

AccessKit already knows the root NodeId and tests focus; it would be much easier to revert to the root id in AccessKit.

Alternatively, AccessKit might actually try to support operations on unknown nodes. It could at least attempt Action::ScrollIntoView.

Or AccessKit could even keep the Node in its own tree as an orphan in this case. It is likely not wrong given that no more up-to-date representation of the Node is available. (Yes, I'm hesitant to suggest this. But, at least for Kas, it is more correct behaviour than panicking because focus does not point at a known Node.)

Linguagem predominante
Rust
Estrelas
1.5k
Forks
127
Merge médio
16h 44min
PRs com merge (30d)
12

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de AccessKit/accesskit

Todas as issues de AccessKit/accesskit

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.