Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#16,316 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
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 が発行され、controlled 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日 23時間
マージ済み PR（30日）
16

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/react-native-windows のほかの issue

microsoft/react-native-windows の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。