You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Upgrading from React 14 to 15 breaks IE11 autofill behavior with controlled inputs #6614
I have a sign in form with controlled inputs that works fine using React 14. When I upgrade to React 15, autofill behavior in IE11 no longer triggers onChange. Strangely, if I change document mode from "Edge (Default)" to "10" React 15 still behaves as expected.
Reading the changelog for R15, this change sounds like it could be related:
Input events are handled more reliably in IE 10 and IE 11; spurious events no longer fire when using a placeholder. @jquense in #4051
I am not sure how the change would affect this. It only keeps changes for the same value from firing more than once. Does IE not fire a native onChange event here? If if does and the value is different it should work. I am wondering if this is still present in master with #5746 which changes the strategy a bit.
I'm not sure. It works in React 0.14.8, but not 15.0.1. So something changed in that release that broke IE. Based on the changelog, #4051 seems to be the likely culprit.
@arendjr Presumably autofill fires some sort of DOM event. When that event fires with the new value, we should fire an onChange event. So the proper path forward is to figure out which event we should be listening to, and add the logic to ensure an onChange fires.
@jimfb: Yes, it does, it fires both "input" and "change" events in this case. The problem is, it doesn't fire the "propertychange" event React listens to.
If you want to know more about which events IE fires, see: https://msdn.microsoft.com/en-us/library/dn629640(v=vs.85).aspx
I have confirmed myself also the tables on that page are correct; so for an auto-fill "input" and "change" fire, but "propertychange" doesn't.
The thing is, except for some specific input types, React never listens to the "change" event, and because of #4051, it doesn't listen to the "input" event anymore either for IE. I've tried to dig into how to fix it, but the conclusion I keep coming back to is that #4051 should be reverted, and #3826 should be applied in its stead.
Maybe I should just create a new PR that does exactly that :)
I've started looking into which events do or don't fire on autofill, but reconciling that with React's source is nontrivial. I'm trying to follow the progress @arendjr has made with identifying specific commits related to the issue.
getting react to listen on specific events in this case should be trivial (provided you know what you are looking at which I admit is not obvious). I don't mind working on it but I won't have access to ie11 still Wednesday or so
@jquense It seems to work fine for the username, but when the password field goes through getTargetInstForInputEventIE for topChange, the activeElement variable is null. I can see the node in targetInst._nativeNode though.
Looks like currently activeElement is only set when the field receives focus. That's won't work for the password field which never fires the focus event.
afaict the simplest fixes are: revert my earlier PR or backport my better one :P
I've looking at the existing code and to my mind the current polyfill approach just won't work with ie11 well. Tbh this issue has probably been present for ie8-9 but the lack usage (or features like autofill) means less folks are likely to notice
and fwiw the changes in master could be back ported without breaking changes if folks wanted to (as I've noted on other such issues). @jimfb can feel free to ping me about it if anyone is interested in that approach
Any updates on this issue? I just implemented some controlled inputs/forms and this was instantly the first defect QA has reported 😞 Is there maybe a workaround I could implement in our code? Unfortunately, IE10+ is the main browser our customers use and without proper autocomplete support I might have to revert all React based forms to something else, creating some kind of frankenstein monster (React components rendering non-React forms)
@simonvizzini I ran into a problem when running selenium tests where the test would type into the search box, but the onChange event was not triggered in React. If this is the same problem your QA is experiencing, my hack was to add an onKeyUp listener to the input so the selenium test could correctly insert text into it.
Activity
jimbolla commentedon Apr 27, 2016
Here's a gist to repro the bug
Steps:
npm installnode_modules\.bin\webpacknode server.jsThis is currently blocking us from upgrading to React 15, as most of our users are on IE11 and expect autofill to work.
jquense commentedon Apr 27, 2016
I am not sure how the change would affect this. It only keeps changes for the same value from firing more than once. Does IE not fire a native onChange event here? If if does and the value is different it should work. I am wondering if this is still present in master with #5746 which changes the strategy a bit.
jimbolla commentedon Apr 27, 2016
IE does not fire onChange on autofill. Supposedly, Safari has similar issues. There's some details in #1159
jquense commentedon Apr 27, 2016
does it fire onInput? how can we know when it happens?
jimbolla commentedon Apr 27, 2016
I'm not sure. It works in React 0.14.8, but not 15.0.1. So something changed in that release that broke IE. Based on the changelog, #4051 seems to be the likely culprit.
jquense commentedon Apr 27, 2016
seems like the different then is that IE10 fires onChange for autofill whereas IE11 does not :/
arendjr commentedon May 11, 2016
@jimfb: Could it be this issue is also related to #6406?
jimfb commentedon May 11, 2016
@arendjr No, I don't think so. #6406 has nothing to do with events.
arendjr commentedon May 11, 2016
Okay thanks, then I'll try to dig a bit deeper to see if I can track this down.
arendjr commentedon May 11, 2016
Okay, can confirm that by reverting #4051 auto-fill issues get fixed for me in IE11.
But that PR was merged to resolve #3826... so what would be the proper way forward here?
jimfb commentedon May 11, 2016
@arendjr Presumably autofill fires some sort of DOM event. When that event fires with the new value, we should fire an onChange event. So the proper path forward is to figure out which event we should be listening to, and add the logic to ensure an onChange fires.
arendjr commentedon May 17, 2016
@jimfb: Yes, it does, it fires both "input" and "change" events in this case. The problem is, it doesn't fire the "propertychange" event React listens to.
If you want to know more about which events IE fires, see: https://msdn.microsoft.com/en-us/library/dn629640(v=vs.85).aspx
I have confirmed myself also the tables on that page are correct; so for an auto-fill "input" and "change" fire, but "propertychange" doesn't.
The thing is, except for some specific input types, React never listens to the "change" event, and because of #4051, it doesn't listen to the "input" event anymore either for IE. I've tried to dig into how to fix it, but the conclusion I keep coming back to is that #4051 should be reverted, and #3826 should be applied in its stead.
Maybe I should just create a new PR that does exactly that :)
8 remaining items
jimbolla commentedon May 29, 2016
I've started looking into which events do or don't fire on autofill, but reconciling that with React's source is nontrivial. I'm trying to follow the progress @arendjr has made with identifying specific commits related to the issue.
For anyone that needs access to IE11 for testing purposes, you can download a Windows VM from Microsoft.
jquense commentedon May 29, 2016
getting react to listen on specific events in this case should be trivial (provided you know what you are looking at which I admit is not obvious). I don't mind working on it but I won't have access to ie11 still Wednesday or so
jimbolla commentedon Jun 6, 2016
@jquense It seems to work fine for the username, but when the password field goes through
getTargetInstForInputEventIEfortopChange, theactiveElementvariable is null. I can see the node intargetInst._nativeNodethough.Looks like currently
activeElementis only set when the field receives focus. That's won't work for the password field which never fires the focus event.IE AutoComplete event handling
jimbolla commentedon Jul 2, 2016
Are the changes in master that should fix this included in the new React 15.2.0 build?
sophiebits commentedon Aug 2, 2016
Probably not, sorry. Still need to find and ship a fix.
jquense commentedon Aug 2, 2016
afaict the simplest fixes are: revert my earlier PR or backport my better one :P
I've looking at the existing code and to my mind the current polyfill approach just won't work with ie11 well. Tbh this issue has probably been present for ie8-9 but the lack usage (or features like autofill) means less folks are likely to notice
jquense commentedon Aug 2, 2016
and fwiw the changes in master could be back ported without breaking changes if folks wanted to (as I've noted on other such issues). @jimfb can feel free to ping me about it if anyone is interested in that approach
special-character commentedon Dec 1, 2016
Are there any updates on when this might be fixed?
Allow simulated native events to propagate
simonvizzini commentedon Mar 30, 2017
Any updates on this issue? I just implemented some controlled inputs/forms and this was instantly the first defect QA has reported 😞 Is there maybe a workaround I could implement in our code? Unfortunately, IE10+ is the main browser our customers use and without proper autocomplete support I might have to revert all React based forms to something else, creating some kind of frankenstein monster (React components rendering non-React forms)
special-character commentedon Mar 30, 2017
@simonvizzini I ran into a problem when running selenium tests where the test would type into the search box, but the onChange event was not triggered in React. If this is the same problem your QA is experiencing, my hack was to add an onKeyUp listener to the input so the selenium test could correctly insert text into it.
Backport input fix (#8575)
Backport input fix (react#8575)
flarnie commentedon Jun 13, 2017
This should be fixed in v15.6.0, which was just released today. Please reopen or open a new issue referencing this one if it still is an issue.