[Webkit-unassigned] [Bug 225148] [selectors] :focus-visible and keyboard events

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed May 5 13:06:42 PDT 2021


https://bugs.webkit.org/show_bug.cgi?id=225148

--- Comment #17 from Rob Dodson <robdodson at chromium.org> ---
Regarding the questions around Ctrl and where all of that came from... 

The short answer is that Slack and Twitter wanted to use keyboard shortcuts to move focus to a different part of the page, but were surprised when that would then show a focus ring. For example, in Slack you can press a shortcut to open a drawer which receives focus, but they didn't want it to match :focus-visible.

So we decided that if the user is pressing a keyboard shortcut that contained a meta/modifier key to move focus, then we would assume they're doing a keyboard shortcut and not match :focus-visible. However, if they were just using something like Esc (or any keypress without a meta/modifier key) to move focus, we would match :focus-visible. This allows you to hit Esc to close a dialog and see the focus indicator on the control that originally opened the dialog.

I wrote a longer history here (https://gist.github.com/robdodson/af9ff157bbdfa6ab5f06fac46854f6ee) with links to various issues and PRs. We tried a few different options and eventually arrived at the current behavior.

> What makes more sense to me is deciding it based on whether some event handler or the default event handler did something in response to a key event or not. Namely, EventHandler::internalKeyEvent returned true.

I think this is a really interesting idea and not something we were able to do with the limitations of the polyfill. The reason I like this idea is because many apps have shortcuts that don't use modifier keys so it would still work for them. The one downside—if I understand correctly—is if the user is pressing Esc to close a dialog then it would not match when focus is returned to whatever control opened the dialog.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210505/cd2548a7/attachment.htm>


More information about the webkit-unassigned mailing list