-
Notifications
You must be signed in to change notification settings - Fork 4.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
Fix Safari Linking: Check for selection range count before calling getRangeAt #15576
Conversation
I was able to reproduce this bug using precisely the steps described with Safari on iMac. |
Doing a codebase search for
Would it be fair to say that if |
Yes, any instances should be updated. I wonder if we can add a custom lint rule here? |
The naive check might be simple enough: But it fails at: window.getSelection().rangeCount > 0 ? window.getSelection().getRangeAt( 0 ) : null; ...unadvisable anyways, re: repeated const selection = window.getSelection();
selection.getRangeAt( 0 ); ...probably the less likely case if doing an unguarded check anyways, and a "better than nothing" allowable false negative. |
An issue for the remaining item / possible ESLint rule: #15606 |
Sorry, when will a fix be available? In the next WordPress release? |
@vesaraiskila yes, WP 5.2.1 |
Thanks @youknowriad Do you know when it will be released? Our site should upgrade to it automatically. |
Sometime next week probably. There's no precise date yet. |
Calling
window.getSelection.getRangeAt(0)
is unsafe without first checking forselection.rangeCount > 0
. In certain situations this can cause unexpected block errors like the gif below. This is most easily reproducible in Safari, but will be inconsistent.To attempt to reproduce:
See also related: Automattic/wp-calypso#32965 and #11209 and potentially #15491
Before:
See https://stackoverflow.com/questions/22935320/uncaught-indexsizeerror-failed-to-execute-getrangeat-on-selection-0-is-not/23699875 for a short example of the
window.getSelection.getRangeAt(0)
issue.Checklist: