-
Notifications
You must be signed in to change notification settings - Fork 24.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Android] [Fixed] - Fix InputAccessoryView crash on Android #33803
Conversation
Base commit: f97c6a5 |
Base commit: 8dded42 |
Thanks for sending this over @hduprat
I'd say we should rather rename the file to be |
Thank you for your suggestion @cortinico , I implemented it. |
Please rebase and it should be green |
8634189
to
5309566
Compare
There's still an error, but I see the CI fails on the main branch too. |
5309566
to
cd629b0
Compare
@cortinico I have just rebased and all tests have finally passed. Thank you for fixing the Android tests 🙏 |
@cortinico has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Libraries/Components/TextInput/__tests__/InputAccessoryView-test.js
Outdated
Show resolved
Hide resolved
if (Platform.OS !== 'ios') { | ||
console.warn('<InputAccessoryView> is only supported on iOS.'); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From an internal discussion:
Since InputAccessoryView is kind of like a "portal" (i.e. components render output is rendered inside a special native container), I think it would be better to make this return null
.
Also, we wouldn't require call sites to use Flow suppressions or hacks.
If we wanted to do this a bit more efficiently (with dead code elimination), we could do something like:
function InputAccessoryView(props: Props): React.Node {
if (Platform.OS === 'ios') {
// Lines 95 - 106.
} else {
console.warn('…');
return null;
}
}
module.exports = InputAccessoryView;
cc @yungsters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated my PR according to the comment.
However, it does not cover the case where InputAccessoryView
wraps a TextInput
- it would display nothing instead of the TextInput
itself. Wouldn't it be considered as a bug later? Or do we want to be clear with developers that InputAccessoryView
should never be used on Android?
Either way, it is better than a crash.
cd629b0
to
2462e4c
Compare
@cortinico has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
This pull request was successfully merged by @hduprat in afa5df1. When will my fix make it into a release? | Upcoming Releases |
Summary
InputAccessoryView
works fine on iOS, but crashes on Android - you can see that by using an Android device on the Expo Snack from the official doc.It forces the developer not to render the component on Android, which is usually good, but other components have implemented other, safer ways to deal with incompatibility issues.
I am of course open to discussion about this change, as well as other implementation ideas.
Changelog
[Android] [Fixed] - Fix InputAccessoryView crash on Android
Test Plan
yarn test
gives out the following output: