Skip to content

fix: avoid undesired reloadInputViews during keyboard dismissal#1235

Merged
kirillzyusko merged 2 commits intomainfrom
fix/undesired-reload-input
Dec 9, 2025
Merged

fix: avoid undesired reloadInputViews during keyboard dismissal#1235
kirillzyusko merged 2 commits intomainfrom
fix/undesired-reload-input

Conversation

@kirillzyusko
Copy link
Copy Markdown
Owner

@kirillzyusko kirillzyusko commented Dec 8, 2025

📜 Description

Fixed issue with non-dismissible keyboard on iOS 26.

💡 Motivation and Context

The problem stems from the fact that we compare 61.66668701171875 vs 61.666666666666664 in old implementation. As a result we were calling UIResponder.reloadInputView too often and during dismissal it caused a keyboard to appear again.

To fix it I added abs(frame.height - desiredHeight) > 0.001 instead of frame.height != desiredHeight. It fixed problem but introduced regression - initial frame had incorrect dimension. It turns out that layoutSubviews wasn't called many times and because of that we didn't specify correct layout. So after creation we need to specify frame. Since we need to do it for modern/legacy views I decided to put common code in default implementation of setupContainerSpecifics and call super.setupContainerSpecifics() from setupContainerSpecifics (in child classes).

Also I wanted to cover this component by e2e tests, but I realized that we can not touch invisible TouchableWithoutFeedback. Then I decided to add button + use KeyboardStickyView, but I discovered too many issues:

  • on Android we don't include KeyboardExtender in keyboard rectangle (known issue);
  • on iOS 26 after re-attaching extender KeyboardStickyView doesn't change its position (iOS 26 specific bug?)

So taking all these issues into account I decided not to fix all of these issues inside one PR. I'll address them later.

Closes #1207

📢 Changelog

iOS

  • use abs(frame.height - desiredHeight) > 0.001 instead of frame.height != desiredHeight;
  • use updateContentFrame(desiredHeight: calculateDesiredHeight()) in default implementation of setupContainerSpecifics;
  • call super.setupContainerSpecifics() from setupContainerSpecifics (in child classes);

🤔 How Has This Been Tested?

Tested in example app.

📸 Screenshots (if appropriate):

Before After
Simulator.Screen.Recording.-.iPhone.17.Pro.-.2025-12-08.at.19.59.39.mov
Simulator.Screen.Recording.-.iPhone.17.Pro.-.2025-12-08.at.19.53.20.mov

📝 Checklist

  • CI successfully passed
  • I added new mocks and corresponding unit-tests if library API was changed

@kirillzyusko kirillzyusko self-assigned this Dec 8, 2025
@kirillzyusko kirillzyusko added 🐛 bug Something isn't working KeyboardExtender 🧩 Anything about keyboard extending (i. e. `KeyboardExtender` component)  iOS 26 Anything specific to iOS 26 labels Dec 8, 2025
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Dec 8, 2025

📊 Package size report

Current size Target Size Difference
230197 bytes 230171 bytes 26 bytes 📈

@kirillzyusko kirillzyusko added the e2e Anything about E2E tests label Dec 9, 2025
@kirillzyusko kirillzyusko removed the e2e Anything about E2E tests label Dec 9, 2025
@kirillzyusko kirillzyusko marked this pull request as ready for review December 9, 2025 09:25
@kirillzyusko kirillzyusko merged commit 5995103 into main Dec 9, 2025
20 checks passed
@kirillzyusko kirillzyusko deleted the fix/undesired-reload-input branch December 9, 2025 09:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🐛 bug Something isn't working  iOS 26 Anything specific to iOS 26 KeyboardExtender 🧩 Anything about keyboard extending (i. e. `KeyboardExtender` component)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dismissing Keyboard when using KeyboardExtender opens keyboard again

1 participant