Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#16,363 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
cpp, react-native
Área
desktop-dev, frontend

Línea de trabajo

Comienza rastreando ComponentView.TryFocus y el punto de entrada solicitado, no mutante, para determinar la posibilidad de recibir el foco en la implementación de Composition. Después inspecciona Composition.FocusManager.FindFirstFocusableElement, FindLastFocusableElement y GettingFocusEventArgs.TrySetNewFocusedComponent, incluida la ruta de activación de IFocusManagerStatics. Se considera terminado cuando la consulta principal está disponible sin mover el foco y el comportamiento de la API secundaria para aplicaciones RNW alojadas está aclarado o corregido.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
C++
Estrellas
17.4k
Forks
1.2k
Merge medio
3 d 10 min
PR fusionados (30 d)
14

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/react-native-windows

Todos los issues de microsoft/react-native-windows

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.