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

[Fabric][Composition] Expose a non-mutating focusability API on  ComponentView  (e.g.  IsFocusable ) for FocusZone / single-tab-stop scenarios

Aberta
  • Algo errado?
#16,363 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
cpp, react-native
Domínio
desktop-dev, frontend

Direção de pesquisa

Comece rastreando ComponentView.TryFocus e o ponto de entrada solicitado e não mutável para verificar a possibilidade de receber foco na implementação de Composition. Em seguida, inspecione Composition.FocusManager.FindFirstFocusableElement, FindLastFocusableElement e GettingFocusEventArgs.TrySetNewFocusedComponent, incluindo o caminho de ativação de IFocusManagerStatics. Considera-se concluído quando a consulta primária estiver disponível sem mover o foco e o comportamento da API secundária para aplicativos RNW hospedados estiver esclarecido ou corrigido.

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

Descrição

bug Invalid Triage Needs: Triage :mag:
Problem Description

Building a FocusZone / single-tab-stop control on Composition (New Architecture) requires identifying the next focusable  ComponentView  in tab order. Today there is no non-mutating way to test whether a  ComponentView  can take focus, so we must call  ComponentView.TryFocus(...)  in a loop — which moves focus as a side effect while probing. We need a query API that reports focusability without changing focus.

What we're doing
Native  RCTFocusZone  implementation. On Tab we want to move focus to the first focusable element outside the zone in one transition; arrow keys navigate within. To find that element we DFS the tree and call  TryFocus  on each candidate until one succeeds, because there's no way to ask "is this focusable?" first.
Gaps

  1. No non-mutating focusability property on  ComponentView . Requesting an  IsFocusable  /  Focusable  (get-only  bool ) property, so we can select the correct target without side-effecting focus.
  2.  Composition.FocusManager.FindFirstFocusableElement  /  FindLastFocusableElement  statics throw — their activation factory ( IFocusManagerStatics ) isn't registered in the runtime we load, so  get_activation_factory  throws (fatal inside a  noexcept  input handler). If these are the intended API, they need to be usable from a hosted RNW app.
  3.  GettingFocusEventArgs.TrySetNewFocusedComponent(ComponentView)  projects as  void  (no success  bool ), so we can't redirect focus during  GettingFocus  and know whether it was accepted, forcing focus logic into  KeyDown  instead.
    Ask
    Primarily (1) a non-mutating focusability query on  ComponentView . Secondarily, clarify/fix (2) and (3) so focus navigation can be built without trial-and-error  TryFocus .
    Workaround
    DFS +  TryFocus  trial-and-error in  KeyDown , which mutates focus while probing and costs a tree walk per keystroke.
Steps To Reproduce
  1. In a react-native-windows Fabric (Composition / New Architecture) app, add a native
    component (e.g. a custom FocusZone) that subclasses the codegen ComponentView and, in
    Initialize, registers a KeyDown handler on the container ComponentView.
  2. In that handler, try to move keyboard focus to the next focusable ComponentView in tab
    order (e.g. on Tab, the first focusable element outside the zone). To do this you must
    determine which ComponentView can accept focus.
  3. Look for a non-mutating way to test whether a given ComponentView is focusable. There is
    none: ComponentView.TryFocus(FocusState) is the only option, and it moves focus as a
    side effect while probing.
  4. Result: you have to call TryFocus in a loop across candidate views, causing focus to
    actually move during probing, and there is no API to identify the correct target up front.
Expected Results

No response

CLI version

CLI version is  13.6.9

Environment
react-native-windows 0.81.5 (Fabric / Composition),  Microsoft.ReactNative  C++/WinRT
Community Modules

No response

Target React Native Architecture

None

Target Platform Version

None

Visual Studio Version

None

Build Configuration

None

Snack, code example, screenshot, or link to a repository

No response

Linguagem predominante
C++
Estrelas
17.4k
Forks
1.2k
Merge médio
2d 23h
PRs com merge (30d)
16

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 microsoft/react-native-windows

Todas as issues de microsoft/react-native-windows

Issues semelhantes

Mais issues de C++

Receba novas issues na sua caixa de entrada

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