Skip to content

[ScreenFooter] - Fix taps absorbed in footer area on Android (physical devices)#3989

Closed
MIchaelZablianov wants to merge 1 commit into
masterfrom
fix/ScreenFooter-Android-tap-fall-through
Closed

[ScreenFooter] - Fix taps absorbed in footer area on Android (physical devices)#3989
MIchaelZablianov wants to merge 1 commit into
masterfrom
fix/ScreenFooter-Android-tap-fall-through

Conversation

@MIchaelZablianov
Copy link
Copy Markdown
Collaborator

Description

On Android physical devices, taps in the empty padding area of ScreenFooter (and therefore FloatingButton, which is now backed by ScreenFooter) are absorbed instead of falling through to content behind. This breaks FlatList items that scroll under a FloatingButton — their onPress never fires.

Root cause: ScreenFooter wraps everything in a Reanimated Animated.View and tries to enable fall-through via pointerEvents="box-none". That prop on a Reanimated Animated.View is unreliable on Android (see referenced upstream issues — pointerEvents is silently ignored, taps in the band are captured).

Reproduces only on Android physical devices (not iOS, not Android emulators).

When the caller doesn't need an entrance animation (animationDuration === 0 — which is what FloatingButton's withoutAnimation prop sets), no transform is needed at all. We add a static-visible short-circuit to both branches (HOISTED and STICKY) that bypasses Reanimated entirely and renders a plain RN View tree. Plain Views honour pointerEvents correctly on Android.

For HOISTED, pointerEvents="box-none" is also forwarded to KeyboardAccessoryView, which propagates it via {...others} to the inner KeyboardTrackingView (a plain RN View on Android). The prop isn't part of KeyboardAccessoryView's typed surface, so the spread + cast {...({pointerEvents: 'box-none'} as object)} is used.

The non-static (animated) branches are intentionally left unchanged — those still rely on pointerEvents on Animated.View and are still subject to the same upstream bug. Solving that requires a separate, more invasive change (e.g. shrinking the Animated.View to wrap only the buttons, or replacing it).

Repro snippet:

<View flex>
  <FlatList ... />
  <FloatingButton
    button={{label: 'Add', onPress: () => {}}}
    visible
    withoutAnimation
    bottomMargin={32}
  />
</View>

On an Android physical device: scroll FlatList items into the FAB band, taps on those items don't fire. With this fix, they do.

Upstream references (why pointerEvents is broken on Reanimated Animated.View on Android):

Changelog

ScreenFooter - Fix taps in the footer's transparent area being absorbed instead of falling through to content behind on Android (physical devices) when animationDuration is 0. Affects FloatingButton with withoutAnimation.

Additional info

N/A

Made with Cursor

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 30, 2026

✅ PR Description Validation Passed

All required sections are properly filled out:

  • Description
  • Changelog
  • Additional info

Your PR is good for review! 🚀


This validation ensures all sections from the PR template are properly filled.

@MIchaelZablianov MIchaelZablianov removed the request for review from lidord-wix April 30, 2026 16:43
@MIchaelZablianov MIchaelZablianov force-pushed the fix/ScreenFooter-Android-tap-fall-through branch 2 times, most recently from 5eceb36 to 1620387 Compare April 30, 2026 17:00
@MIchaelZablianov MIchaelZablianov force-pushed the fix/ScreenFooter-Android-tap-fall-through branch from 1620387 to f5fa07c Compare April 30, 2026 17:01

const childrenArray = React.Children.toArray(children).slice(0, 3).map(renderChild);

const isStaticVisible = animationDuration === 0 && visible;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line has a good potential for a better solution (a little less footprint and a little more readable IMO).

Click to see a hint How is `animationDuration === 0` called in `FloatingButton`?

@M-i-k-e-l
Copy link
Copy Markdown
Collaborator

Also, did you go over the description? :)

@MIchaelZablianov
Copy link
Copy Markdown
Collaborator Author

work on it continued in #3990

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants