fix(pointer): backport #16140 (PointerRoutedAway + ScrollView contentOffset DIP) to 0.83-stable

[FaithfulAudio]

[0.83-stable] Backport #16140: ScrollView Pressables stuck / dead tap on high-DPI displays

Backport of #16140 ("Fix ScrollView Pressables stuck and dead tap on high-DPI displays", merged to main 2026-05-13, commit df07be9) onto 0.83-stable. Original fix by @gmacmaster; #16140 was itself the main cherry-pick of #16139 ("[0.84] Fix ScrollView Pressables stay stuck and next tap is dead on high-DPI displays", merged to 0.84-stable). All credit for the diagnosis and the fix belongs to that work — this PR only carries it back to 0.83. Fixes #16047 ("Scrolling Views not working with touch screen devices") on 0.83.

0.83-stable does not contain any of it today — PointerRoutedAway and the pointScaleFactor division in updateStateWithContentOffset both have zero hits at that ref.

Problem

In a Fabric/Composition app on a touch device:

1. A Pressable/TouchableOpacity inside a ScrollView stays stuck in its pressed state after the finger starts a scroll, and a later tap elsewhere can be attributed to that originally-pressed target.
2. On a Windows display scale other than 100%, after any scroll the next tap on a row does not fire press at all.

Root cause

Two independent defects, exactly as diagnosed in #16047 / #16140:

(a) m_activeTouches keeps a zombie entry when ScrollView redirects the pointer.
ScrollViewComponentView calls VisualInteractionSource::TryRedirectForManipulation, and the OS reassigns the pointer to the InteractionTracker. WinAppSDK does not raise PointerCaptureLost on our InputPointerSource for that path — it raises PointerRoutedAway, which CompositionEventHandler never subscribed to. After the redirect we get no PointerMoved / PointerReleased / PointerCaptureLost for that pointer, so the active-touch entry is never erased and the pressed Pressable never receives a cancel.

(b) ScrollView writes physical pixels into a DIP-typed state field.
ScrollViewComponentView::updateStateWithContentOffset() stored m_scrollVisual.ScrollPosition() straight into ScrollViewShadowNode::ConcreteState::Data::contentOffset. ScrollPosition() is in physical pixels — the scroll visual is sized layoutMetrics.frame.size.* * pointScaleFactor (see updateLayoutMetrics / updateContentVisualSize) — but contentOffset is consumed as DIPs. So JS UIManager.measure() over-subtracted the offset by pointScaleFactor after any scroll on a >100% scale, and Pressability fired LEAVE_PRESS_RECT synchronously inside pressIn, suppressing press. Every other consumer in the same file already divides by pointScaleFactor — getScrollMetrics(), ScrollInteractionTrackerOwner::ValuesChanged(), and hitTest(); only the state write did not.

Additionally, ScrollMomentumEnd was the one scroll-completion path that did not call updateStateWithContentOffset() (ScrollBeginDrag and ScrollEndDrag both do), so the last inertia delta could leave contentOffset stale even with the unit fix in place.

Fix

Three files, matching #16140:

• CompositionEventHandler.cpp / .h — subscribe to InputPointerSource.PointerRoutedAway, add onPointerRoutedAway, which cancels and erases the active touch for that pointer; add m_pointerRoutedAwayToken and unsubscribe it in the destructor alongside the other pointer tokens.
• ScrollViewComponentView.cpp — divide ScrollPosition() by pointScaleFactor (guarded to 1.0f when non-positive) before writing contentOffset. The scrollbar components keep receiving the raw physical-pixel position, which is what they expect.
• ScrollViewComponentView.cpp — call updateStateWithContentOffset() at the top of the ScrollMomentumEnd handler, before notifying JS.

How this differs from #16140 on main — please read

A literal cherry-pick cannot build on 0.83-stable, because #16140 was written on top of infrastructure that only exists on main. DispatchSynthesizedTouchCancelForActiveTouch and CancelActiveTouchForPointerInternal both have zero occurrences in CompositionEventHandler.{cpp,h} at 0.83-stable, so the merged form of onPointerRoutedAway would not resolve.

• On main, onPointerCaptureLost already contained an active-touch cancel block, and Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140 refactored it into a shared CancelActiveTouchForPointerInternal() helper built on DispatchSynthesizedTouchCancelForActiveTouch(). Neither the pre-existing cancel block nor either helper exists on 0.83-stable. This backport therefore implements onPointerRoutedAway as a standalone function using the 0.83-era DispatchTouchEvent(TouchEventType::Cancel, ...) API, and looks the entry up with the std::find_if over pair.second.touch.identifier pattern already used by onPointerPressed and onPointerReleased in this same file. Net effect on the redirect path is identical.
• Consequently onPointerCaptureLost is left untouched here. On main Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140 rewrote that function; on 0.83-stable there is nothing there to rewrite, and adding capture-loss cleanup is separate work — it is the subject of my other 0.83-stable PR, #16333, so I have deliberately kept it out of this one so the two review independently. I tested both stacking orders locally with git apply: on a clean 0.83-stable base each applies at exit 0, and applying one then the other also succeeds at exit 0 (with git apply reducing context by a line or two, since fix(fabric): touch-input reliability — primary-button labeling, guaranteed touch END/CANCEL, phantom active-touch self-heal #16333 inserts a block just inside onPointerCaptureLost's closing brace and this PR appends a new function just after it). There is no semantic overlap — worst case one of us rebases. Happy to sequence them however you prefer.
• Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140 also added #include "ReactNativeIsland.h" to ScrollViewComponentView.cpp. Nothing in the backported code needs it on 0.83-stable, so it is omitted.
• The code comments are Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140's own comments verbatim, with one added trailing line in onPointerRoutedAway (// (later taps can then be attributed to that original target).) carried over from the main onPointerCaptureLost comment, since 0.83-stable has no equivalent comment nearby. Drop it if you would rather the text match Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140 exactly.

I diffed the added-line sets against #16140 to confirm this: the only things that differ are the onPointerRoutedAway body, the main-only helper/onPointerCaptureLost refactor, the ReactNativeIsland.h include, and that one comment line. Everything else — the PointerRoutedAway subscription lambda, the destructor unsubscribe, the header declaration, m_pointerRoutedAwayToken, the pointScaleFactor division block, and the momentum-end call — is byte-for-byte identical to #16140.

Validation

• git apply --check against 0.83-stable is clean for all three files — exit 0 both strictly and with --recount -C2, verified against the three files exactly as they stand at this ref.
• The change is running in a production RNW 0.83.2 new-arch app (Facilitron FIT), compiled from source with UseExperimentalNuget=false, so the patched Microsoft.ReactNative is what the app actually loads — not a prebuilt NuGet. The app carries these hunks as a yarn patch against the react-native-windows npm package (npm-package paths map to this repo by adding the vnext/ prefix), which is what this PR upstreams.
• Behavioural validation of the original fix is in [0.84] Fix ScrollView Pressables stay stuck and next tap is dead on high-DPI displays #16139 / Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140 / Scrolling Views not working with touch screen devices #16047; I am not re-claiming it here.

What I have not verified — please weigh these before merging:

• I have not re-run the Scrolling Views not working with touch screen devices #16047 repro (touch-scroll a ScrollView, then tap a row, at 125%/150% display scale) as an isolated before/after A/B against this 0.83-stable backport specifically. My confidence rests on the added lines being byte-identical to Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140 outside the documented deltas, not on a fresh A/B. If you would rather see that A/B before merging, say so and I will run it; alternatively confirm that Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140's validation is considered sufficient for a same-content backport.
• No CI has run on this branch. RNW's unit/E2E suites have not been executed against these three files at 0.83-stable. Azure Pipelines on this repo is gated behind a maintainer comment, so I cannot start it myself — a /azp run would be appreciated.

Caveats for reviewers:

• The onPointerCaptureLost divergence above is the thing to check. Because 0.83-stable's onPointerCaptureLost has no active-touch cleanup, the touch-cancel coverage on this branch after merging only this PR is narrower than on main: the ScrollView redirect path is fixed, but other system-driven capture losses (focus change, another window stealing input) still leak. That gap is intentional scope separation, not an oversight.
• I chose std::find_if over pair.second.touch.identifier rather than main's m_activeTouches.find(pointerId), purely to match the surrounding 0.83 code. The two are equivalent here (the map key is the pointer id); happy to switch to the plain find.
• If you would rather I mirror Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140 exactly by also introducing DispatchSynthesizedTouchCancelForActiveTouch + CancelActiveTouchForPointerInternal on 0.83-stable, say so and I will — it just pulls in more of main than a minimal backport needs, and it collides with fix(fabric): touch-input reliability — primary-button labeling, guaranteed touch END/CANCEL, phantom active-touch self-heal #16333.
• The pointScaleFactor > 0.0f ? ... : 1.0f guard is Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140's; keeping it avoids a divide-by-zero if updateStateWithContentOffset() ever runs before the first updateLayoutMetrics.
• The scrollbar components intentionally still get the raw physical-pixel offset — m_verticalScrollbarComponent->ContentOffset(rawScrollPosition) receives exactly the same value the pre-patch code passed, so scrollbar behaviour is unchanged by construction. (The scrollbar helper stores it and multiplies incoming DIP hit-test points by m_scaleFactor, i.e. it works in physical pixels internally.) Only the shadow-node state is converted.
• Change file included (type: patch). Let me know if you would prefer prerelease to match Fix ScrollView Pressables stuck and dead tap on high-DPI displays #16140's own change file.

Microsoft Reviewers: Open in CodeFlow

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.