Description
RCTScrollViewComponentView.prepareForRecycle does not reset contentInset, so a scroll view that was given a keyboard-derived contentInset.bottom by _keyboardWillChangeFrame: carries that inset into the next screen that reuses the recycled view.
The result is a scroll surface with a large phantom bottom inset: real, non-rubber-band, scrollable blank space below the content that does not spring back. It appears on screens that have nothing to do with keyboards, is healed only by relaunching the app, and is invisible to any inspection of the affected screen's own code.
There is a second contributing factor: _keyboardWillChangeFrame: trusts a keyboard frame whose origin.y is 0, which iOS publishes while a modal is being dismissed with the keyboard up.
Mechanism
React/Fabric/Mounting/ComponentViews/ScrollView/RCTScrollViewComponentView.mm (0.81.5):
1. The inset is computed from the keyboard frame's top edge (~L190-200):
CGPoint absoluteViewOrigin = [self convertPoint:self.bounds.origin toView:nil];
CGFloat scrollViewLowerY = isInverted ? absoluteViewOrigin.y : absoluteViewOrigin.y + self.bounds.size.height;
UIEdgeInsets newEdgeInsets = _scrollView.contentInset;
CGFloat inset = MAX(scrollViewLowerY - keyboardEndFrame.origin.y, 0);
...
newEdgeInsets.bottom = MAX(inset, props.contentInset.bottom);
If keyboardEndFrame.origin.y == 0, inset becomes scrollViewLowerY — the scroll view's own lower edge in window coordinates. There is an existing special case for a degenerate keyboard frame just below (UIAccessibilityPrefersCrossFadeTransitions() + size.height == 0), but it only covers that accessibility setting and only the zero-height variant.
2. prepareForRecycle never restores the inset (~L616):
- (void)prepareForRecycle
{
[super prepareForRecycle];
_state.reset();
const auto &props = static_cast<const ScrollViewProps &>(*_props);
_scrollView.contentOffset = RCTCGPointFromPoint(props.contentOffset);
_scrollView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;
_shouldUpdateContentInsetAdjustmentBehavior = YES;
_isUserTriggeredScrolling = NO;
CGRect oldFrame = self.frame;
self.frame = CGRectZero;
self.frame = oldFrame;
_contentView = nil;
_prevFirstVisibleFrame = CGRectZero;
_firstVisibleView = nil;
}contentOffset is restored from props on exactly this principle; contentInset and verticalScrollIndicatorInsets are not.
3. updateProps: cannot repair it on the next mount. oldScrollViewProps is derived from *_props (not from the oldProps argument), and prepareForRecycle does not reset _props, so on a recycled view the contentInset diff gate compares the previous props against the new ones — both default zero — and never fires. The stale UIKit value survives.
Reproduction shape
- A screen with
automaticallyAdjustKeyboardInsets on a ScrollView/FlatList (in our case a chat thread presented modally, with the text input focused).
- Dismiss that modal while the keyboard is up. iOS publishes a keyboard frame with
origin.y == 0; the list is stamped with contentInset.bottom == <its own lower Y>.
- Open any other screen containing any scroll view. It receives the recycled component view and inherits the inset.
Every subsequently mounted scroll surface is affected; surfaces mounted before the event are not; relaunching clears it (the recycle pool is gone).
Evidence
Measured on device (iPhone, 390x844 logical, Release build), by instrumenting onScroll and reading nativeEvent on three unrelated screens, two of which contain no keyboard-aware components at all:
Settings content 1751 frame 753 contentInset top 0 bottom 700
AccountDetails content 1276 frame 727 contentInset top 0 bottom 700
TransactionDetail content 1153 frame 727 contentInset top 0 bottom 700
The inset was identical (700) across all three routes, across 7 separate visits and 605 scroll samples, while content heights and frames varied. 844 − 700 = 144, which is exactly the height of the chat composer plus the home indicator — i.e. 700 is the chat list's own lower Y, minted on that screen and carried elsewhere.
Reachable scroll extent matched contentSize + contentInset.bottom − frame in every sample, confirming the extra travel is inset rather than content.
Suggested fix
In prepareForRecycle, restore the inset state from props alongside the existing contentOffset restore:
_scrollView.contentInset = RCTUIEdgeInsetsFromEdgeInsets(props.contentInset);
_scrollView.verticalScrollIndicatorInsets = RCTUIEdgeInsetsFromEdgeInsets(props.scrollIndicatorInsets);
Optionally, also ignore a degenerate keyboard frame in _keyboardWillChangeFrame:, since origin.y is the reference for every value the method derives (both the inset and contentDiff):
if (keyboardEndFrame.origin.y <= 0) {
return;
}A docked keyboard's top edge is always strictly positive on iPhone.
Notes
Surveying the other Fabric component views in 0.81.5, RCTScrollViewComponentView appears to be the only one that mutates UIKit state from an NSNotificationCenter observer (i.e. outside the props lifecycle), which is why the omission only bites here. RCTVirtualViewComponentView explicitly resets self.hidden in its own prepareForRecycle, which suggests this is an oversight rather than intent.
Version
React Native 0.81.5, iOS, New Architecture (Fabric), Hermes.
Description
RCTScrollViewComponentView.prepareForRecycledoes not resetcontentInset, so a scroll view that was given a keyboard-derivedcontentInset.bottomby_keyboardWillChangeFrame:carries that inset into the next screen that reuses the recycled view.The result is a scroll surface with a large phantom bottom inset: real, non-rubber-band, scrollable blank space below the content that does not spring back. It appears on screens that have nothing to do with keyboards, is healed only by relaunching the app, and is invisible to any inspection of the affected screen's own code.
There is a second contributing factor:
_keyboardWillChangeFrame:trusts a keyboard frame whoseorigin.yis0, which iOS publishes while a modal is being dismissed with the keyboard up.Mechanism
React/Fabric/Mounting/ComponentViews/ScrollView/RCTScrollViewComponentView.mm(0.81.5):1. The inset is computed from the keyboard frame's top edge (~L190-200):
If
keyboardEndFrame.origin.y == 0,insetbecomesscrollViewLowerY— the scroll view's own lower edge in window coordinates. There is an existing special case for a degenerate keyboard frame just below (UIAccessibilityPrefersCrossFadeTransitions()+size.height == 0), but it only covers that accessibility setting and only the zero-height variant.2.
prepareForRecyclenever restores the inset (~L616):contentOffsetis restored from props on exactly this principle;contentInsetandverticalScrollIndicatorInsetsare not.3.
updateProps:cannot repair it on the next mount.oldScrollViewPropsis derived from*_props(not from theoldPropsargument), andprepareForRecycledoes not reset_props, so on a recycled view thecontentInsetdiff gate compares the previous props against the new ones — both default zero — and never fires. The stale UIKit value survives.Reproduction shape
automaticallyAdjustKeyboardInsetson aScrollView/FlatList(in our case a chat thread presented modally, with the text input focused).origin.y == 0; the list is stamped withcontentInset.bottom == <its own lower Y>.Every subsequently mounted scroll surface is affected; surfaces mounted before the event are not; relaunching clears it (the recycle pool is gone).
Evidence
Measured on device (iPhone, 390x844 logical, Release build), by instrumenting
onScrolland readingnativeEventon three unrelated screens, two of which contain no keyboard-aware components at all:The inset was identical (700) across all three routes, across 7 separate visits and 605 scroll samples, while content heights and frames varied.
844 − 700 = 144, which is exactly the height of the chat composer plus the home indicator — i.e. 700 is the chat list's own lower Y, minted on that screen and carried elsewhere.Reachable scroll extent matched
contentSize + contentInset.bottom − framein every sample, confirming the extra travel is inset rather than content.Suggested fix
In
prepareForRecycle, restore the inset state from props alongside the existingcontentOffsetrestore:Optionally, also ignore a degenerate keyboard frame in
_keyboardWillChangeFrame:, sinceorigin.yis the reference for every value the method derives (both the inset andcontentDiff):A docked keyboard's top edge is always strictly positive on iPhone.
Notes
Surveying the other Fabric component views in 0.81.5,
RCTScrollViewComponentViewappears to be the only one that mutates UIKit state from anNSNotificationCenterobserver (i.e. outside the props lifecycle), which is why the omission only bites here.RCTVirtualViewComponentViewexplicitly resetsself.hiddenin its ownprepareForRecycle, which suggests this is an oversight rather than intent.Version
React Native 0.81.5, iOS, New Architecture (Fabric), Hermes.