-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Microsoft Edge - easily enters a confused state via ctrl-a + keypress and crashes #7270
Conversation
Microsoft Edge exposes TextInput event, but it's not useful either.
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! |
I should be more clear about TextEvent issue in Edge. This issue is caused because "TextEvent" in Edge fires twice in the final key sequence. There is an extra TextEvent with data="" if "ctrl-a" is used to make the selection after "j" is pressed. Only ctrl-a. It's very strange. Edge type a (TextEvent data="a") Chrome type a (TextEvent data="a") Bypassing TextEvent support seemed to be the easiest fix. I didn't want to go into why "ctrl-a" was firing a blank event. Even more strange is if you do "shift-arrow-up" to select the text instead, you don't get the double text-events fired ((TextEvent data="")(TextEvent data="j")) but instead what is expected (just (TextEvent data="a")) |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
@msmania Any idea what's going on here or if this fix seems reasonable? I am hesitant to add UA tests without a version bound. |
Sorry for the late response.. I agree with @spicyj because there are known issues in the fallback logic, especially in IME-related scenarios such as #7107 . |
I confirmed the JS exception 'NotFoundError' was caused by incorrect DOM operation in Edge, and it was irrespectively fixed in the Anniversary Update to address another DOM issue. @butchmarshall can you please install the Anniversary Update and check the behavior? Given that the latest Edge does not have this issue, I'd like to keep React using textInput events for Edge, instead of the fallback logic. I tried to apply the same fix to Windows 10 1511, but unfortunately it cannot be a simple backport due to refactoring and design changes. You can report this issue here, but because there is higher risk, I'm afraid that this single case would not rise to the bar needed for backporting. |
Can we add a UA test for older versions of Edge? @msmania Maybe you can suggest what version strings we can look for? |
It's great to see Microsoft fixing these issues! Thanks for keeping this bug up to date everyone. |
Ping @msmania, is there a recommended version string we can add here to catch only releases with this issue? |
@aweary, Sorry for not responding for long. It's a good idea to detect Edge's version from UA, but using the fallback logic in older Edge still looks risky to me. I remember the root cause of this issue was that Edge removed an element which should not be removed. After that, when React tries to remove that element which does no longer exist, an exception occurs, then React enters a confused state. So the workaround would be to handle such an unexpected DOM operation. Anyway, Edge's UA string format is described here, and the build versions of Win10 family can be found here. Either "EdgeVersion >= 14" or "Win10Build >= 14393" is good for this purpose. Below is an example of UA string from Edge in Win10 1607 and 1511: <Win10 1607> <Win10 1511> |
Seems like this got fixed in Edge. |
Microsoft Edge exposes TextInput event, but it's not useful either.
See opened issue here