fix: use IsPrimary() for touch pointer isPrimary instead of hardcoded id#16099
Merged
acoates-ms merged 2 commits intoMay 11, 2026
Conversation
… ID check (#4) activeTouch.isPrimary was set via `pointerId == 1`, which only works for mouse (MOUSE_POINTER_ID == 1). Windows touch pointer IDs are OS-allocated and essentially never 1, so isPrimary was always false for touch input. This meant touch pointers never triggered onClick (gated behind isPrimary && button == 0) and reported incorrect isPrimary in PointerEvents sent to JS. Replace with pointerPoint.Properties().IsPrimary(), which reads the OS POINTER_FLAG_PRIMARY flag directly. This API is already used elsewhere in the codebase (SwitchComponentView, WindowsTextInputComponentView, Composition.Input). (The diagnostics are pre-existing clang noise from missing PCH/Windows headers — not related to this change.)
Contributor
|
/azp run |
Contributor
|
Azure Pipelines successfully started running 1 pipeline(s). |
Performance Test ResultsBranch: ✅ Passed161 scenario(s) across 28 suite(s) — no regressionsSectionList
FlatList
TouchableOpacity
ScrollView
TouchableHighlight
Pressable
Modal
Image
ActivityIndicator
Switch
Button
TextInput
View
Text
SectionList.native-perf-test.ts
FlatList.native-perf-test.ts
TouchableHighlight.native-perf-test.ts
TouchableOpacity.native-perf-test.ts
Pressable.native-perf-test.ts
ScrollView.native-perf-test.ts
ActivityIndicator.native-perf-test.ts
TextInput.native-perf-test.ts
Switch.native-perf-test.ts
Button.native-perf-test.ts
Modal.native-perf-test.ts
Image.native-perf-test.ts
View.native-perf-test.ts
Text.native-perf-test.ts
|
acoates-ms
approved these changes
May 11, 2026
acoates-ms
added a commit
that referenced
this pull request
May 12, 2026
…16119) * fix: cancel zombie touch state on ScrollView pointer capture loss (#3) (#16100) When a touch-screen user scrolls a ScrollView, the OS redirects the pointer to the InteractionTracker via TryRedirectForManipulation and fires PointerCaptureLost. The existing handler only cleaned up touches when JS-level CapturePointer was active (m_pointerCapturingComponentTag != -1), which ScrollView never uses. This left a zombie entry in m_activeTouches that kept Pressables visually stuck in a pressed state and caused subsequent taps to replay events against the original target. Three changes: 1. Extend onPointerCaptureLost to unconditionally cancel the active touch for the specific pointer that lost capture, regardless of whether JS-level CapturePointer was ever issued. 2. Remove the always-true fallback in IsPointerWithinInitialTree that walked from activeTouch.touch.target (always the initial view) back to initialTag, returning true on iteration 1 and bypassing the correct W3C hit-test check. This caused onClick to fire even when the pointer was released over a different target. 3. Scope per-pointer event dispatch in DispatchTouchEvent to only the pointer that actually changed, instead of iterating every entry in m_activeTouches. The old loop fired onPointerDown/Move/Up/Cancel for all active touches, producing duplicated events in multi-touch scenarios and replaying events on zombie targets. * Image does not consistently rerender on image source change (#16107) * Image does not consistently rerender on image source change * Change files * fix e2e test? * Add hideTitleBar and hideBorder to Modal (#16108) * Add hideTitleBar and hideBorder to Modal * Change files * format * lint fix (type fixes) * snapshot * fix: use IsPrimary() for touch pointer isPrimary instead of hardcoded id (#16099) * Create react-native-windows-4ad3ddaf-1358-4ff0-9971-38a7db68266c.json * fix: use IsPrimary() for touch pointer isPrimary instead of hardcoded ID check (#4) activeTouch.isPrimary was set via `pointerId == 1`, which only works for mouse (MOUSE_POINTER_ID == 1). Windows touch pointer IDs are OS-allocated and essentially never 1, so isPrimary was always false for touch input. This meant touch pointers never triggered onClick (gated behind isPrimary && button == 0) and reported incorrect isPrimary in PointerEvents sent to JS. Replace with pointerPoint.Properties().IsPrimary(), which reads the OS POINTER_FLAG_PRIMARY flag directly. This API is already used elsewhere in the codebase (SwitchComponentView, WindowsTextInputComponentView, Composition.Input). (The diagnostics are pre-existing clang noise from missing PCH/Windows headers — not related to this change.) * update codegen files * lint --------- Co-authored-by: Gordon MacMaster <31481849+gmacmaster@users.noreply.github.com>
acoates-ms
pushed a commit
that referenced
this pull request
May 12, 2026
… id (#16099) (#16121) * Create react-native-windows-4ad3ddaf-1358-4ff0-9971-38a7db68266c.json * fix: use IsPrimary() for touch pointer isPrimary instead of hardcoded ID check (#4) activeTouch.isPrimary was set via `pointerId == 1`, which only works for mouse (MOUSE_POINTER_ID == 1). Windows touch pointer IDs are OS-allocated and essentially never 1, so isPrimary was always false for touch input. This meant touch pointers never triggered onClick (gated behind isPrimary && button == 0) and reported incorrect isPrimary in PointerEvents sent to JS. Replace with pointerPoint.Properties().IsPrimary(), which reads the OS POINTER_FLAG_PRIMARY flag directly. This API is already used elsewhere in the codebase (SwitchComponentView, WindowsTextInputComponentView, Composition.Input). (The diagnostics are pre-existing clang noise from missing PCH/Windows headers — not related to this change.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
activeTouch.isPrimary was set via
pointerId == 1, which only works formouse (MOUSE_POINTER_ID == 1). Windows touch pointer IDs are OS-allocated
and essentially never 1, so isPrimary was always false for touch input.
This meant touch pointers never triggered onClick (gated behind
isPrimary && button == 0) and reported incorrect isPrimary in
PointerEvents sent to JS.
Type of Change
Why
Replace with pointerPoint.Properties().IsPrimary(), which reads the OS
POINTER_FLAG_PRIMARY flag directly. This API is already used elsewhere
in the codebase (SwitchComponentView, WindowsTextInputComponentView,
Composition.Input).
Resolves: N/a
What
Today, touch fingers never trigger onClick (because isPrimary is always false). After the fix, the primary finger would. Combined with secondary fix 1 above, those new clicks would be dispatched correctly per W3C — but they are still new dispatches that did not happen before. That is a behaviour change worth its own changeset, its own review, and its own test pass.
Changelog
Should this change be included in the release notes: yes
fix: use IsPrimary() for touch pointer isPrimary instead of hardcoded pointer ID check
Microsoft Reviewers: Open in CodeFlow