-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
fix: textinput onchange event order fix #45377
fix: textinput onchange event order fix #45377
Conversation
Base commit: 52dc7a8 |
@arushikesarwani94 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@arushikesarwani94 Any update here? |
Hi @shubhamguptadream11 - this looks to effectively revert #36930, which fixed #36494. Can you check whether this change reintroduces that bug? If so we might need a different approach. |
Hi @shubhamguptadream11 thank you for this PR. I see that it is Old Architecture only. I'd like to point out that the desired behaviour is what we have in text input components in the New Architecture. Could you please validate that your changes are consistent with what we have in the New Architecture? |
@robhogan @dmytrorykun Thanks for you suggestion. |
I did some debugging around this and trying to map the flow between old and new architecture. In both the cases textViewDidChangeSelection function is called from this file:
Now since for the first KeyPress This will further call: In New Architecture(fileName: RCTTextInputComponentView) we are using 2 flags to control the flow:
In Old Architecture(fileName: RCTBaseTextInputView) this is only responsible to call onSelectionChange event, without utilising any flags.
Note: textInputDidChange is responsible for emitting onChange event. Possible Solution: We should utilise comingFromJs and _ignoreNextTextInputCall flags to match the flow in Old Arch. Apart from above mentioned changes there are changes in other functions as well like |
This PR is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days |
1 similar comment
This PR is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days |
Summary:
Fixes the first issue mentioned here: #45018
Changelog:
[IOS] [FIXED]
Issue details?
In iOS for the multiline
textinput
, for the first keypress onSelectionChange fires first, but for later key presses onChangeText/onChange fire first.What's the expected behaviour?
Ideally
onChange
should be beforeonSelectionChange
for everykeyPress
.Why this is happening?
https://github.com/facebook/react-native/blob/52dc7a832666532b457bda736c5fe4095f31f731/packages/react-native/Libraries/Text/TextInput/RCTBackedTextInputDelegateAdapter.mm#L269C2-L278C1
This function is called when we do onKeyPress but since
_lastStringStateWasUpdatedWith
is nil initially so it didn't goes under if case and callstextViewProbablyDidChangeSelection
which internally callsonSelectionChange
event through this methodtextInputDidChangeSelection
. After thistextInputDidChange
is called. Due to this flow order of event is reversed.Solution
By removing
_lastStringStateWasUpdatedWith
check from if case we are making sure that this flow of methods become same as per other keypress where events are in correct flow.So this will trigger
textViewDidChange
which will triggeronChange
event correctlyNow since just after this call we are setting
_ignoreNextTextInputCall=YES
this will prevent any further calls totextViewDidChange
and after this if block is finished we are already callingtextViewProbablyDidChangeSelection
which will callonSelectionChange
, preserving the correct flow.Also, If we check implementation of this in Fabric here in this file:
https://github.com/facebook/react-native/blob/main/packages/react-native/React/Fabric/Mounting/ComponentViews/TextInput/RCTTextInputComponentView.mm#L392C2-L405C2
We can clearly see that there isn't any check applied for
_lastStringStateWasUpdatedWith
. Triggering the correct flow.Test Plan:
Logs coming on first keypress after fix: