… iOS

Implements a runtime swizzling fix for React Native 0.81+ bug where
ScrollView's contentInset area fails to respond to touch events. This
prevents users from initiating scroll gestures by touching the inset
padding area, which is critical for chat UX patterns where contentInset
positions messages at the top of the screen.

## Problem

React Native's RCTScrollViewComponentView.betterHitTest returns the
container view (self) instead of the underlying UIScrollView instance
when the touch is in the contentInset area. This causes touch events
to be intercepted by the container, preventing the scroll view from
receiving gestures.

Upstream issue: facebook/react-native#54123

## Solution

Uses Objective-C runtime method swizzling to override hitTest:withEvent:
on the ScrollView's container view. The fix mirrors the upstream patch:

- Calls the original hitTest:withEvent: implementation
- When the result is self (the container) - which is the bug - dynamically
  finds and returns the UIScrollView child instead
- Otherwise preserves the original result (subviews, nil, etc.)

Key implementation detail: the UIScrollView is looked up dynamically at
hit-test time rather than captured during swizzling. This ensures the
fix works across React Native hot reloads and full refreshes where the
view hierarchy is recreated but the swizzled class persists.

Implementation follows the same pattern as PR kirillzyusko#1336's scrollRectToVisible
fix: dynamic subclass creation with idempotent prefix check, applied lazily
in didMoveToWindow.

## Benefits

✅ Users can now scroll by touching contentInset area
✅ Interactive content (Pressables, buttons, inputs) continues to work normally
✅ Survives React Native hot reloads and full refreshes
✅ Fixes chat UX where messages need top positioning via contentInset
✅ Non-breaking: defensive implementation returns early if structure unexpected
✅ Compatible with existing scrollRectToVisible noop fix
✅ Zero-cost for apps not using ClippingScrollView
✅ Provides immediate relief while waiting for upstream React Native fix

## Performance Considerations

The dynamic scrollView lookup only executes when:
- The original hitTest returns the container (empty space/contentInset area)
- NOT when touching actual content (messages, buttons, etc.)

Cost: iterating through container's direct subviews (typically 1-3 views)
- UIScrollView + maybe scroll indicators
- Just pointer comparisons and class checks
- Negligible performance impact

## Risks and Considerations

⚠️ Runtime swizzling: Fragile if React Native's view hierarchy changes
   Mitigation: Defensive checks, silently returns if container not found

⚠️ Dynamic lookup on every hit test in contentInset area: Small overhead
   Mitigation: Only 1-3 subviews to check, only runs for empty space touches

⚠️ React Native version variations: Different RN versions may have different hierarchies
   Mitigation: Graceful degradation - no fix applied but doesn't break

⚠️ Calling original implementation: Assumes it's safe to invoke
   Mitigation: Standard ObjC pattern, same lifetime guarantees as the view

## Testing Recommendations

- Test contentInset with top/bottom/left/right values
- Verify touch in contentInset area initiates scroll
- Verify interactive elements (Pressables, buttons, inputs) remain functional
- Test with inverted ScrollViews (chat pattern)
- Verify behavior persists after hot reload
- Verify behavior persists after full refresh
- Test keyboard interactions remain functional
- Verify no console warnings
- Test on iOS 17+ with React Native 0.81+

## Technical Details

Implementation in ClippingScrollViewDecoratorViewManager.mm:
- Added KCApplyFixedHitTest() function that swizzles hitTest:withEvent:
- Modified didMoveToWindow() to apply both fixes
- Captures original IMP and calls it via function pointer
- Conditional: if (result == self) lookup and return UIScrollView child
- Dynamic lookup avoids stale references across RN refreshes
- Uses KC_FixedHitTest_ prefix for idempotent check

… iOS

Implements a runtime swizzling fix for React Native 0.81+ bug where
ScrollView's contentInset area fails to respond to touch events. This
prevents users from initiating scroll gestures by touching the inset
padding area, which is critical for chat UX patterns where contentInset
positions messages at the top of the screen.

## Problem

React Native's RCTScrollViewComponentView.betterHitTest returns the
container view (self) instead of the underlying UIScrollView instance
when the touch is in the contentInset area. This causes touch events
to be intercepted by the container, preventing the scroll view from
receiving gestures.

Upstream issue: facebook/react-native#54123

## Solution

Uses Objective-C runtime method swizzling to override hitTest:withEvent:
on the ScrollView's container view. The fix mirrors the upstream patch:

- Calls the original hitTest:withEvent: implementation
- When the result is self (the container) - which is the bug - dynamically
  finds and returns the UIScrollView child instead
- Otherwise preserves the original result (subviews, nil, etc.)

Key implementation detail: the UIScrollView is looked up dynamically at
hit-test time rather than captured during swizzling. This ensures the
fix works across React Native hot reloads and full refreshes where the
view hierarchy is recreated but the swizzled class persists.

Implementation follows the same pattern as PR kirillzyusko#1336's scrollRectToVisible
fix: dynamic subclass creation with idempotent prefix check, applied lazily
in didMoveToWindow.

## Benefits

✅ Users can now scroll by touching contentInset area
✅ Interactive content (Pressables, buttons, inputs) continues to work normally
✅ Survives React Native hot reloads and full refreshes
✅ Fixes chat UX where messages need top positioning via contentInset
✅ Non-breaking: defensive implementation returns early if structure unexpected
✅ Compatible with existing scrollRectToVisible noop fix
✅ Zero-cost for apps not using ClippingScrollView
✅ Provides immediate relief while waiting for upstream React Native fix

## Performance Considerations

The dynamic scrollView lookup only executes when:
- The original hitTest returns the container (empty space/contentInset area)
- NOT when touching actual content (messages, buttons, etc.)

Cost: iterating through container's direct subviews (typically 1-3 views)
- UIScrollView + maybe scroll indicators
- Just pointer comparisons and class checks
- Negligible performance impact

## Risks and Considerations

⚠️ Runtime swizzling: Fragile if React Native's view hierarchy changes
   Mitigation: Defensive checks, silently returns if container not found

⚠️ Dynamic lookup on every hit test in contentInset area: Small overhead
   Mitigation: Only 1-3 subviews to check, only runs for empty space touches

⚠️ React Native version variations: Different RN versions may have different hierarchies
   Mitigation: Graceful degradation - no fix applied but doesn't break

⚠️ Calling original implementation: Assumes it's safe to invoke
   Mitigation: Standard ObjC pattern, same lifetime guarantees as the view

## Testing Recommendations

- Test contentInset with top/bottom/left/right values
- Verify touch in contentInset area initiates scroll
- Verify interactive elements (Pressables, buttons, inputs) remain functional
- Test with inverted ScrollViews (chat pattern)
- Verify behavior persists after hot reload
- Verify behavior persists after full refresh
- Test keyboard interactions remain functional
- Verify no console warnings
- Test on iOS 17+ with React Native 0.81+

## Technical Details

Implementation in ClippingScrollViewDecoratorViewManager.mm:
- Added KCApplyFixedHitTest() function that swizzles hitTest:withEvent:
- Modified didMoveToWindow() to apply both fixes
- Captures original IMP and calls it via function pointer
- Conditional: if (result == self) lookup and return UIScrollView child
- Dynamic lookup avoids stale references across RN refreshes
- Uses KC_FixedHitTest_ prefix for idempotent check

… iOS

Implements a runtime swizzling fix for React Native 0.81+ bug where
ScrollView's contentInset area fails to respond to touch events. This
prevents users from initiating scroll gestures by touching the inset
padding area, which is critical for chat UX patterns where contentInset
positions messages at the top of the screen.

## Problem

React Native's RCTScrollViewComponentView.betterHitTest returns the
container view (self) instead of the underlying UIScrollView instance
when the touch is in the contentInset area. This causes touch events
to be intercepted by the container, preventing the scroll view from
receiving gestures.

Upstream issue: facebook/react-native#54123

## Solution

Uses Objective-C runtime method swizzling to override hitTest:withEvent:
on the ScrollView's container view. The fix mirrors the upstream patch:

- Calls the original hitTest:withEvent: implementation
- When the result is self (the container) - which is the bug - dynamically
  finds and returns the UIScrollView child instead
- Otherwise preserves the original result (subviews, nil, etc.)

Key implementation detail: the UIScrollView is looked up dynamically at
hit-test time rather than captured during swizzling. This ensures the
fix works across React Native hot reloads and full refreshes where the
view hierarchy is recreated but the swizzled class persists.

Implementation follows the same pattern as PR kirillzyusko#1336's scrollRectToVisible
fix: dynamic subclass creation with idempotent prefix check, applied lazily
in didMoveToWindow.

## Benefits

✅ Users can now scroll by touching contentInset area
✅ Interactive content (Pressables, buttons, inputs) continues to work normally
✅ Survives React Native hot reloads and full refreshes
✅ Fixes chat UX where messages need top positioning via contentInset
✅ Non-breaking: defensive implementation returns early if structure unexpected
✅ Compatible with existing scrollRectToVisible noop fix
✅ Zero-cost for apps not using ClippingScrollView
✅ Provides immediate relief while waiting for upstream React Native fix

## Performance Considerations

The dynamic scrollView lookup only executes when:
- The original hitTest returns the container (empty space/contentInset area)
- NOT when touching actual content (messages, buttons, etc.)

Cost: iterating through container's direct subviews (typically 1-3 views)
- UIScrollView + maybe scroll indicators
- Just pointer comparisons and class checks
- Negligible performance impact

## Risks and Considerations

⚠️ Runtime swizzling: Fragile if React Native's view hierarchy changes
   Mitigation: Defensive checks, silently returns if container not found

⚠️ Dynamic lookup on every hit test in contentInset area: Small overhead
   Mitigation: Only 1-3 subviews to check, only runs for empty space touches

⚠️ React Native version variations: Different RN versions may have different hierarchies
   Mitigation: Graceful degradation - no fix applied but doesn't break

⚠️ Calling original implementation: Assumes it's safe to invoke
   Mitigation: Standard ObjC pattern, same lifetime guarantees as the view

## Testing Recommendations

- Test contentInset with top/bottom/left/right values
- Verify touch in contentInset area initiates scroll
- Verify interactive elements (Pressables, buttons, inputs) remain functional
- Test with inverted ScrollViews (chat pattern)
- Verify behavior persists after hot reload
- Verify behavior persists after full refresh
- Test keyboard interactions remain functional
- Verify no console warnings
- Test on iOS 17+ with React Native 0.81+

## Technical Details

Implementation in ClippingScrollViewDecoratorViewManager.mm:
- Added KCApplyFixedHitTest() function that swizzles hitTest:withEvent:
- Modified didMoveToWindow() to apply both fixes
- Captures original IMP and calls it via function pointer
- Conditional: if (result == self) lookup and return UIScrollView child
- Dynamic lookup avoids stale references across RN refreshes
- Uses KC_FixedHitTest_ prefix for idempotent check

… iOS

Implements a runtime swizzling fix for React Native 0.81+ bug where
ScrollView's contentInset area fails to respond to touch events. This
prevents users from initiating scroll gestures by touching the inset
padding area, which is critical for chat UX patterns where contentInset
positions messages at the top of the screen.

## Problem

React Native's RCTScrollViewComponentView.betterHitTest returns the
container view (self) instead of the underlying UIScrollView instance
when the touch is in the contentInset area. This causes touch events
to be intercepted by the container, preventing the scroll view from
receiving gestures.

Upstream issue: facebook/react-native#54123

## Solution

Uses Objective-C runtime method swizzling to override hitTest:withEvent:
on the ScrollView's container view. The fix mirrors the upstream patch:

- Calls the original hitTest:withEvent: implementation
- When the result is self (the container) - which is the bug - dynamically
  finds and returns the UIScrollView child instead
- Otherwise preserves the original result (subviews, nil, etc.)

Key implementation detail: the UIScrollView is looked up dynamically at
hit-test time rather than captured during swizzling. This ensures the
fix works across React Native hot reloads and full refreshes where the
view hierarchy is recreated but the swizzled class persists.

Implementation follows the same pattern as PR kirillzyusko#1336's scrollRectToVisible
fix: dynamic subclass creation with idempotent prefix check, applied lazily
in didMoveToWindow.

## Benefits

✅ Users can now scroll by touching contentInset area
✅ Interactive content (Pressables, buttons, inputs) continues to work normally
✅ Survives React Native hot reloads and full refreshes
✅ Fixes chat UX where messages need top positioning via contentInset
✅ Non-breaking: defensive implementation returns early if structure unexpected
✅ Compatible with existing scrollRectToVisible noop fix
✅ Zero-cost for apps not using ClippingScrollView
✅ Provides immediate relief while waiting for upstream React Native fix

## Performance Considerations

The dynamic scrollView lookup only executes when:
- The original hitTest returns the container (empty space/contentInset area)
- NOT when touching actual content (messages, buttons, etc.)

Cost: iterating through container's direct subviews (typically 1-3 views)
- UIScrollView + maybe scroll indicators
- Just pointer comparisons and class checks
- Negligible performance impact

## Risks and Considerations

⚠️ Runtime swizzling: Fragile if React Native's view hierarchy changes
   Mitigation: Defensive checks, silently returns if container not found

⚠️ Dynamic lookup on every hit test in contentInset area: Small overhead
   Mitigation: Only 1-3 subviews to check, only runs for empty space touches

⚠️ React Native version variations: Different RN versions may have different hierarchies
   Mitigation: Graceful degradation - no fix applied but doesn't break

⚠️ Calling original implementation: Assumes it's safe to invoke
   Mitigation: Standard ObjC pattern, same lifetime guarantees as the view

## Testing Recommendations

- Test contentInset with top/bottom/left/right values
- Verify touch in contentInset area initiates scroll
- Verify interactive elements (Pressables, buttons, inputs) remain functional
- Test with inverted ScrollViews (chat pattern)
- Verify behavior persists after hot reload
- Verify behavior persists after full refresh
- Test keyboard interactions remain functional
- Verify no console warnings
- Test on iOS 17+ with React Native 0.81+

## Technical Details

Implementation in ClippingScrollViewDecoratorViewManager.mm:
- Added KCApplyFixedHitTest() function that swizzles hitTest:withEvent:
- Modified didMoveToWindow() to apply both fixes
- Captures original IMP and calls it via function pointer
- Conditional: if (result == self) lookup and return UIScrollView child
- Dynamic lookup avoids stale references across RN refreshes
- Uses KC_FixedHitTest_ prefix for idempotent check

… iOS

Implements a runtime swizzling fix for React Native 0.81+ bug where
ScrollView's contentInset area fails to respond to touch events. This
prevents users from initiating scroll gestures by touching the inset
padding area, which is critical for chat UX patterns where contentInset
positions messages at the top of the screen.

## Problem

React Native's RCTScrollViewComponentView.betterHitTest returns the
container view (self) instead of the underlying UIScrollView instance
when the touch is in the contentInset area. This causes touch events
to be intercepted by the container, preventing the scroll view from
receiving gestures.

Upstream issue: facebook/react-native#54123

## Solution

Uses Objective-C runtime method swizzling to override hitTest:withEvent:
on the ScrollView's container view. The fix mirrors the upstream patch:

- Calls the original hitTest:withEvent: implementation
- When the result is self (the container) - which is the bug - dynamically
  finds and returns the UIScrollView child instead
- Otherwise preserves the original result (subviews, nil, etc.)

Key implementation detail: the UIScrollView is looked up dynamically at
hit-test time rather than captured during swizzling. This ensures the
fix works across React Native hot reloads and full refreshes where the
view hierarchy is recreated but the swizzled class persists.

Implementation follows the same pattern as PR kirillzyusko#1336's scrollRectToVisible
fix: dynamic subclass creation with idempotent prefix check, applied lazily
in didMoveToWindow.

## Benefits

✅ Users can now scroll by touching contentInset area
✅ Interactive content (Pressables, buttons, inputs) continues to work normally
✅ Survives React Native hot reloads and full refreshes
✅ Fixes chat UX where messages need top positioning via contentInset
✅ Non-breaking: defensive implementation returns early if structure unexpected
✅ Compatible with existing scrollRectToVisible noop fix
✅ Zero-cost for apps not using ClippingScrollView
✅ Provides immediate relief while waiting for upstream React Native fix

## Performance Considerations

The dynamic scrollView lookup only executes when:
- The original hitTest returns the container (empty space/contentInset area)
- NOT when touching actual content (messages, buttons, etc.)

Cost: iterating through container's direct subviews (typically 1-3 views)
- UIScrollView + maybe scroll indicators
- Just pointer comparisons and class checks
- Negligible performance impact

## Risks and Considerations

⚠️ Runtime swizzling: Fragile if React Native's view hierarchy changes
   Mitigation: Defensive checks, silently returns if container not found

⚠️ Dynamic lookup on every hit test in contentInset area: Small overhead
   Mitigation: Only 1-3 subviews to check, only runs for empty space touches

⚠️ React Native version variations: Different RN versions may have different hierarchies
   Mitigation: Graceful degradation - no fix applied but doesn't break

⚠️ Calling original implementation: Assumes it's safe to invoke
   Mitigation: Standard ObjC pattern, same lifetime guarantees as the view

## Testing Recommendations

- Test contentInset with top/bottom/left/right values
- Verify touch in contentInset area initiates scroll
- Verify interactive elements (Pressables, buttons, inputs) remain functional
- Test with inverted ScrollViews (chat pattern)
- Verify behavior persists after hot reload
- Verify behavior persists after full refresh
- Test keyboard interactions remain functional
- Verify no console warnings
- Test on iOS 17+ with React Native 0.81+

## Technical Details

Implementation in ClippingScrollViewDecoratorViewManager.mm:
- Added KCApplyFixedHitTest() function that swizzles hitTest:withEvent:
- Modified didMoveToWindow() to apply both fixes
- Captures original IMP and calls it via function pointer
- Conditional: if (result == self) lookup and return UIScrollView child
- Dynamic lookup avoids stale references across RN refreshes
- Uses KC_FixedHitTest_ prefix for idempotent check