Fix/issue 5693 firefox focus trap #11601
Conversation
|
@tofumatt Please let me know if anything is "off" with the PR as it's pretty much my first one, happy to update or run anything locally that I forgot to to get tests passing or whatever! |
There was a problem hiding this comment.
Thanks for the PR @timwright12! A few meta points around the PR:
- no need to reference this PR in the original issue; GitHub does that for us so it's just extra notifications/noise that isn't needed 😄
- You can use "Fixes #xyz" in the issue description so the issue you're working on fixing will be closed automatically once the patch lands
- You should remove the addition of the
gutenberg-mobilesubmodule; that was removed awhile back and shouldn't be committed 😄
Otherwise the process around everything looks good 👍
This looks good but I think could use comments that clarify things a bit more; right now this code would be a bit confusing to a developer unaware of this bug or the reason for this code to exist.
Normally I'd also advocate for an E2E (end-to-end) test here, but our E2E tests run in Chromium on Linux so 🤷♂️ Since the code path is still the same it might be nice to test it and make sure that keyboard presses work as intended, but we won't really be testing the browser/OS combo that caused the bug in the first place…
Thanks for the patch, let me know if anything needs clarification, but I think after some comment tweaks this'll be good to merge! 👍
| @@ -137,6 +137,32 @@ class URLInput extends Component { | |||
| // If the suggestions are not shown or loading, we shouldn't handle the arrow keys | |||
| // We shouldn't preventDefault to allow block arrow keys navigation | |||
| if ( ! showSuggestions || ! posts.length || loading ) { | |||
| // This switch statement corrects a bug in Windows Firefox | |||
There was a problem hiding this comment.
Is there anymore context for this bug? What causes it? Is there a link explaining what's happening here or what the bug is?
It would be helpful for future developers to get a bit more info here 😄
The info you wrote up in the original issue (
#5693 (comment)) was handy, so even including that or parts of it (and then linking to the comment for more context) would be great!
| event.stopPropagation(); | ||
| event.preventDefault(); | ||
|
|
||
| // Set the inpit caret to the last position |
| // This switch statement corrects a bug in Windows Firefox | ||
| switch ( event.keyCode ) { | ||
| case UP: { | ||
| // If the caret is not in position 0 |
There was a problem hiding this comment.
This comment is pretty much describing the if condition below, which is pretty easy to read. But the point here is the caret should be moved to the beginning if it's not there when UP is pressed; it might be better to just explain that here or above the CASE UP: line. 🤷♂️
Description
Fixes #5693
How has this been tested?
Browser this fix in tested in Chrome, Safari, Firefox, Windows Firefox
Types of changes
Interrupted the key event on inputURL if the caret position isn't at the beginning or end of the input field text to mimic the expected behavior in non-Win FF browsers
Checklist: