Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Fabric: core Switch renders but never fires onValueChange on mouse click (new architecture)

未关闭
  • 哪里不对？
#16,316 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
58/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
cpp, react-native
领域
desktop, frontend

调研方向

从 vnext/Microsoft.ReactNative/Fabric/Composition/SwitchComponentView.cpp 开始，重点关注 OnPointerPressed、OnPointerReleased 和 IsPrimary() 检查。跟踪鼠标释放是否到达 view，以及 gate 是否接受它，然后添加 issue 中描述的交互测试。当合成的鼠标点击发出 SwitchEventEmitter::onChange 并更新受控 Switch 时，即表示完成。

由索引模型根据 Issue 内容生成。

描述

Needs: Triage :mag:

Environment

  • react-native-windows 0.83.2 (component source unchanged on main as 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); }} />;
}
  1. Run on react-native-windows with the new architecture enabled.
  2. 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 to toggle() (~line 328), which emits facebook::react::SwitchEventEmitter::onChange — the native event behind onValueChange.
  • Both OnPointerPressed (~line 262) and OnPointerReleased early-return unless args.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.

主要语言
C++
星标
17.4k
派生
1.2k
平均合并
2 天 17 小时
30 天内合并 PR
13

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/react-native-windows 的其他 Issue

查看 microsoft/react-native-windows 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。