[m-bert]

Description

manualActivation: true has never worked on macOS — the handler activated on its own as if the flag wasn't set. Found while verifying a review comment on #4387. Four stacked defects in RNManualActivationRecognizer, all macOS-specific:

1. The failure requirement was never established. The blocking mechanism relies on shouldBeRequiredToFailByGestureRecognizer:, which is a UIGestureRecognizer subclass hook (UIGestureRecognizerSubclass.h). NSGestureRecognizer has no such hook, so AppKit never called it and the handler's recognizer never waited for the blocker — a pan activated straight from mouse-down. AppKit only consults the delegate; since the blocker is already its own NSGestureRecognizerDelegate, the two-arg delegate callback now forwards to the shared logic.

2. AppKit does not reliably deny the dependent recognizer when the blocker recognizes. On iOS, the blocker completing (Began → Ended in its action handler) causes UIKit to fail the recognizer that required it to fail — that's how a released-without-activate() gesture is discarded. On AppKit, completing the blocker can instead flush the dependent recognizer's buffered recognition: with the requirement in place, releasing after a drag delivered the pan's entire withheld sequence (Began/Changed/Ended with the full accumulated translation) instead of discarding it, while a motionless press-release was discarded correctly (traced with state-transition logging). The blocker now explicitly fails the handler's recognizer before completing.

3. The release-without-activation cleanup was dead code. The original macOS port (macOS Support #2588) crossed the touchesBegan/touchesEnded bodies: mouseDown incremented _activePointers and then checked if (_activePointers == 0) — never true after an increment — while mouseUp only decremented. The zero-check now lives in mouseUp, mirroring touchesEnded on iOS.

4. Stale pointer count after a JS activate(). stopActivationBlocker disables the blocker, so it misses the subsequent mouse-up; iOS recovers in touchesCancelled, which has no AppKit equivalent. The count would stay at 1 and the cleanup in (3) would never fire again. reset now zeroes _activePointers.

Test plan

Tested on the following code:

import React, { useEffect } from 'react';
import { StyleSheet, Text, View } from 'react-native';
import {
  GestureDetector,
  GestureStateManager,
  usePanGesture,
} from 'react-native-gesture-handler';
import { useSharedValue } from 'react-native-reanimated';

export default function EmptyExample() {
  // Box A: manualActivation, JS never calls activate().
  // Expected: every press/drag/release cycle logs onBegin -> onFinalize canceled=true,
  // never onActivate, and behaves identically on every repeat.
  const neverActivatePan = usePanGesture({
    manualActivation: true,
    onBegin: () => console.log('[never-activate] onBegin'),
    onActivate: () => console.log('[never-activate] onActivate (SHOULD NOT HAPPEN)'),
    onDeactivate: () => console.log('[never-activate] onDeactivate'),
    onFinalize: (e) => console.log(`[never-activate] onFinalize canceled=${e.canceled}`),
  });

  // Box B: manualActivation, activates itself from a timer while the button is held
  // (onTouchesMove is not delivered on macOS — separate bug).
  // Expected: hold past 300 ms -> onActivate (tx ~0), onUpdate while dragging,
  // onDeactivate + onFinalize canceled=false on release. Release before 300 ms ->
  // canceled=true and the late activate() is a no-op.
  const selfTag = useSharedValue(-1);
  const selfActivatePan = usePanGesture({
    manualActivation: true,
    onTouchesDown: () => {
      const tag = selfTag.value;
      setTimeout(() => {
        console.log(`[self-activate] calling activate(${tag})`);
        GestureStateManager.activate(tag);
      }, 300);
    },
    onBegin: () => console.log('[self-activate] onBegin'),
    onActivate: (e) =>
      console.log(`[self-activate] onActivate tx=${e.translationX.toFixed(1)} ty=${e.translationY.toFixed(1)}`),
    onUpdate: (e) =>
      console.log(`[self-activate] onUpdate tx=${e.translationX.toFixed(1)} ty=${e.translationY.toFixed(1)}`),
    onDeactivate: () => console.log('[self-activate] onDeactivate'),
    onFinalize: (e) => console.log(`[self-activate] onFinalize canceled=${e.canceled}`),
  });

  useEffect(() => {
    selfTag.value = selfActivatePan.handlerTag;
  }, [selfActivatePan.handlerTag, selfTag]);

  return (
    <View style={styles.container}>
      <Text style={styles.label}>A: manualActivation, never activated — click & drag, release</Text>
      <GestureDetector gesture={neverActivatePan}>
        <View style={[styles.box, { backgroundColor: 'darkorange' }]} />
      </GestureDetector>

      <Text style={styles.label}>B: manualActivation, self-activates 300 ms after press</Text>
      <GestureDetector gesture={selfActivatePan}>
        <View style={[styles.box, { backgroundColor: 'mediumpurple' }]} />
      </GestureDetector>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center', gap: 8 },
  label: { marginTop: 16, fontSize: 15, opacity: 0.6 },
  box: { width: 150, height: 150, borderRadius: 12 },
});

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8c232aea-131a-458d-9aba-db8b8ccdc66d

📥 Commits

Reviewing files that changed from the base of the PR and between 9a4f06d and c96efd4.

📒 Files selected for processing (1)

• packages/react-native-gesture-handler/apple/RNManualActivationRecognizer.m

🚧 Files skipped from review as they are similar to previous changes (1)

• packages/react-native-gesture-handler/apple/RNManualActivationRecognizer.m

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • Improved macOS gesture handling by correctly failing dependent gestures before completion.
  • Reset pointer tracking state reliably when gestures are reset.
  • Aligned macOS gesture behavior with iOS for failure dependencies.

Walkthrough

Changes

macOS manual activation recognizer

Layer / File(s)	Summary
Recognizer lifecycle and failure coordination packages/react-native-gesture-handler/apple/RNManualActivationRecognizer.m	macOS gesture completion now fails the dependent recognizer before ending. reset clears _activePointers. The macOS delegate forwards failure-requirement checks to the shared implementation. Mouse tracking behavior remains unchanged.

Possibly related PRs

• software-mansion/react-native-gesture-handler#4390: Modifies related macOS gesture handling and pointer or touch event lifecycle behavior.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the macOS-specific fix for manualActivation handlers that activate without explicit activation.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

Fixes macOS-specific manual activation behavior so manualActivation: true actually blocks a handler from auto-activating until JS explicitly calls activate(), aligning AppKit behavior more closely with iOS expectations.

Changes:

• Ensure the activation blocker establishes the required-to-fail relationship on macOS via the AppKit delegate callback.
• Explicitly fail the handler recognizer when the blocker recognizes (to prevent buffered/withheld recognition from being flushed on release).
• Correct macOS pointer-count bookkeeping and reset behavior to avoid stale _activePointers across disable/enable cycles.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[j-piasecki]

Are the claude-looking comments really needed?

[m-bert]

Are the claude-looking comments really needed?

50/50 I'd say (c96efd4)