-
Notifications
You must be signed in to change notification settings - Fork 46.4k
-
Notifications
You must be signed in to change notification settings - Fork 46.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
onChange doesn't fire if input re-renders due to a setState() in a non-React capture phase listener #13424
Comments
@gaearon I would love to take this one whats the difficulty level? |
I’m not sure but since it has always been broken I guess it’s not the easiest one. I’m not even sure it can be solved nicely. |
@gaearon Can it be solved by passing the input value at that moment along before running setState? react/packages/react-reconciler/src/ReactFiberClassComponent.js Lines 174 to 190 in 672e859
|
Maybe, I haven't dived deep into it. Send a PR? |
Sorry I can't figure out another way but add another snapshot argument, which is ugly... so let it be |
Instead of using this |
The issue here is not only because of non-React capture phase listener . I have a separate use case reproducing the same issue, since react makes batch updates to state once per event handler so if multiple events are attached (eg onKeydown and onChange) here onKeydown handler triggers a state update using the useReducer hook which in turn triggers a re-render thus re-setting the updated/changed DOM node value to what is present in the state thus not firing onChange event at all.
|
Oh man, I wish I'd stumbled across this thread earlier - was banging my head against this issue for a while and thought I was going insane. I managed to reproduce my simplified use case here. I have an application where I've started to add in keyboard shortcuts, hence why I was making use of What I was seeing in my app while I was trying to debug this really confused me. When I added While I appreciate that it might not be pragmatic to try and fix what might be considered an "extremely rare" issue; how realistic would it be to add a warning for users about this potential conflict? Maybe even just adding a "N.B." to the documentation? When I searched for "addEventListener" on the reactjs.org site it took me to Handling Events. Maybe a note here could save people some hassle? Or making a "Gotchas" page for known edge-case issues like this that are known but aren't going to be fixed anytime soon? In any case, thanks for filing this issue in the first place - it gave me some much needed closure! |
I got this issue on a requirement where the select file dialog should automatically open when the form is opened/rendered/mounted (like an autofocus behaviour). I can't avoid the form re-render due to other code's part. In this case, the select file dialog opens but the input file onChange event doesn't trigger when the user confirms the select the files. Edit: in case someone is having the same required and is looking for a solution, I did a workaround by creating a second input outside the form. |
I have come across this bug in practice - mouse coordinates are kept in state and communicated via props. The result is that controlled select elements are inoperable by the mouse, but work fine with the keyboard. |
Hi Can you show me what did you do on your work around please ? Thank you ! |
I was able to leverage queueMicrotask https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask without having to move the input out. @peluprvi |
Repro with React 18 and hooks: https://codesandbox.io/s/react-18-onchange-dropped-if-re-rendered-in-non-react-capture-listener-forked-slrhyh |
Extracting from #12643.
This issue has always been in React. I can reproduce it up to React 0.11. However it's probably extremely rare in practice and isn't worth fixing. I'm just filing this for posterity.
Here is a minimal example.
Typing doesn't work — unless I comment out that
setState
call in the capture phase listener.Say the input is empty and we're typing
a
.What happens here is that
setState({})
in the capture phase non-React listener runs first. When re-rendering due to that first emptysetState({})
, input props still contain the old value (""
) while the DOM node's value is new ("a"
). They're not equal, so we'll set the DOM node value to""
(according to the props) and remember""
as the current value.Then,
ChangeEventPlugin
tries to decide whether to emit a change event. It asks the tracker whether the value has changed. The tracker compares the presumably "new"node.value
(it's""
— we've just set it earlier!) with thelastValue
it has stored (also""
— and also just updated). No changes!Our
"a"
update is lost. We never get the change event, and never actually get a chance to set the correct state.The text was updated successfully, but these errors were encountered: