Fabric: core Switch renders but never fires onValueChange on mouse click (new architecture)
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 58/100
Direzione di ricerca
Inizia in vnext/Microsoft.ReactNative/Fabric/Composition/SwitchComponentView.cpp, concentrandoti su OnPointerPressed, OnPointerReleased e sui controlli IsPrimary(). Verifica se il rilascio del mouse raggiunge la view e se il controllo lo accetta, quindi aggiungi il test di interazione descritto nell'issue. Il lavoro è completato quando un clic del mouse sintetizzato emette SwitchEventEmitter::onChange e aggiorna lo Switch controllato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Environment
- react-native-windows 0.83.2 (component source unchanged on
mainas of 2026-07-17), new architecture (Fabric, composition), Win32/HWND host - Windows 11, physical mouse input
- Reproduced in a production app; repro is trivial (any core
Switch)
Steps to reproduce
import {Switch} from 'react-native';
function Repro() {
const [on, setOn] = React.useState(false);
return <Switch value={on} onValueChange={v => { console.log('onValueChange', v); setOn(v); }} />;
}
- Run on react-native-windows with the new architecture enabled.
- Click the Switch with the mouse.
Expected
onValueChange fires with the toggled value; the Switch (a controlled component) re-renders in the new state. This is the behavior on Android/iOS.
Actual
The Switch renders correctly (including hover visuals), but onValueChange never fires on mouse click. No JS callback, no state change — the control is effectively inert for mouse users.
Root cause pointer
vnext/Microsoft.ReactNative/Fabric/Composition/SwitchComponentView.cpp (current main):
OnPointerReleased(~line 285) is the only mouse path totoggle()(~line 328), which emitsfacebook::react::SwitchEventEmitter::onChange— the native event behindonValueChange.- Both
OnPointerPressed(~line 262) andOnPointerReleasedearly-return unlessargs.GetCurrentPoint(-1).Properties().IsPrimary()is true.
On our device the emitter never fires for mouse clicks, so either the IsPrimary() gate rejects mouse pointer input on this code path, or OnPointerReleased is never routed to the Switch component view at all (pointer capture/hit-test). We have not stepped through native to disambiguate the two; what is proven on-device is that no onChange event reaches JS for any mouse click, on multiple screens and multiple Switch instances. The keyboard path (OnKeyUp, Space, ~line 318) is separate and was not part of this investigation.
Suggested fix
Ensure the pointer-released path reaches toggle() for mouse input: verify PointerRoutedEventArgs::GetCurrentPoint(-1).Properties().IsPrimary() returns true for mouse-generated pointer events in the composition input pipeline (or drop the IsPrimary() gate for mouse pointer devices), and add an interaction test that asserts SwitchEventEmitter::onChange fires on a synthesized mouse click.
Workaround (what we ship today)
Wrap the Switch in a Pressable that owns the interaction, and make the Switch itself inert:
<Pressable onPress={() => setOn(v => !v)}>
<Switch value={on} pointerEvents="none" />
</Pressable>
The Pressable receives the click and toggles state; the Switch is display-only. This restores mouse operation but bypasses the control's own accessibility/interaction semantics.
- Lingua principale
- C++
- Stelle
- 17.4k
- Fork
- 1.2k
- Merge medio
- 2g 17h
- PR unite (30g)
- 13
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/react-native-windows
-
Fabric text is drawn with ClearType onto transparent composition surfaces, fringing thin glyphsApertaNeeds: Triage :mag:
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
microsoft/react-native-windows#16340 ·
I maintainer di solito rispondono entro 2 giorni
-
bug Needs: Triage :mag:
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
microsoft/react-native-windows#16321 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Needs: Triage :mag:
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
microsoft/react-native-windows#16442 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Fabric: activating the window doesn't announce the window or the focused control to a screen readerApertaNeeds: Triage :mag:
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
microsoft/react-native-windows#16435 ·
I maintainer di solito rispondono entro 2 giorni
-
bug Needs: Triage :mag:
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
microsoft/react-native-windows#16410 ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di microsoft/react-native-windows
Issue simili
-
Status: Awaiting triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
espressif/arduino-esp32#12984 ·
I maintainer di solito rispondono entro 1 giorno
-
torch_ops/logprob.cu does not compile with the serving container's nvcc (13.3.73); check_torch_ops.py cannot run as shippedForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 Meno di un'ora Idoneità per principianti 72/100
ashhart/TensorFold#535 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
agent:Windows bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno