[mozzius]

Summary:

ScrollView's automaticallyAdjustKeyboardInsets only applied or removed the keyboard inset in response to a UIKeyboardWillChangeFrameNotification. _keyboardWillChangeFrame: returns early while the flag is off, and updateProps only stores the flag's new value. So changing the prop while the keyboard is already on screen does nothing:

• Turned on while the keyboard is up: no inset. The end of the content stays behind the keyboard until the keyboard is hidden and shown again.
• Turned off while the keyboard is up: the inset stays. The keyboard's hide notification is ignored too, since the prop is now off, so the inset is never removed and there's a keyboard-sized gap at the end of the content for good.

We hit the first case in the Bluesky app. Our bottom sheets turn the prop on only once the sheet reports it's at its full-height detent, which arrives as an event from native. A sheet with an autofocused TextInput raises the keyboard during presentation, before that event lands, so the sheet couldn't scroll to its submit button.

This change:

• stores the keyboard's end frame from every notification, including while the prop is off
• moves the inset calculation out of _keyboardWillChangeFrame: into _adjustInsetsForKeyboardEndFrame:keyboardBeginFrame:duration:curve:, unchanged
• when updateProps sees the prop change and the view is in a window with the keyboard visible:
  • turning it on runs that calculation for the current keyboard frame, as if the keyboard had just appeared, without animation. It also scrolls a focused input inside the ScrollView into view, as a real keyboard notification does.
  • turning it off resets the keyboard edge of contentInset (and the vertical indicator insets) to the contentInset prop, then clamps the content offset to the smaller scrollable range through scrollTo:.
• runs after super updateProps:, so it sees the new contentInset prop, which is applied earlier in updateProps.

If the keyboard is hidden, or the view isn't in a window yet (e.g. a recycled view getting its props before it's mounted), nothing changes, and the next keyboard notification is handled as before.

Fixes #59305

Changelog:

[IOS] [FIXED] - ScrollView now applies or removes its keyboard inset when automaticallyAdjustKeyboardInsets changes while the keyboard is visible

Test Plan:

With the repro from #59305 (https://github.com/mozzius/scrollview-keyboard-insets-repro). Its fixed branch applies this exact change to RN 0.88.0 built from source (RCT_USE_PREBUILT_RNCORE=0). iPhone 17 simulator, iOS 26.5, Release, keyboard height 335pt. contentInset.bottom as reported by onScroll:

Scenario	stock	with this change
Control: prop on before the keyboard appears	335	335
Prop turned on with the keyboard up	0, end of the content stuck behind the keyboard	335, end of the content scrolls above the keyboard
Prop turned off with the keyboard up, then keyboard hidden	335, permanent gap under the content	0 (removed as soon as the prop turns off)

Also with this change:

• flipping the prop while the keyboard is hidden changes nothing: the inset stays 0 and the content doesn't move.
• normal show and hide with the prop on from the start behaves the same as stock.

RNTester's ScrollView "Keyboard Insets" example already has a Switch for automaticallyAdjustKeyboardInsets, so the same steps should show it there: focus an input, then flip the Switch. I tested with the standalone repro rather than RNTester.

clang-format (the repo's pinned 21.1.2) makes no changes. The repro's patch is the same change applied to 0.88.0, where one hunk needed rebasing by hand around a line that only exists on main.

Related:

• [iOS] Fix ScrollView stale keyboard inset after dismiss #56189 fixes a stale gap after dismissal with contentInsetAdjustmentBehavior="automatic", in the offset clamping.
• [iOS][Fabric] Reset keyboard inset state when recycling ScrollViews #57791 fixes keyboard inset state across recycling. The part of it still open is in prepareForRecycle, which this change doesn't touch.

🤖 Generated with Claude Code