Spin off issue from #22261 (https://bugs.webkit.org/show_bug.cgi?id=22261#c82) In that issue, the maintainers assert: > Mac users expect the focus to remain in the text field if you click on a button. That’s what happens everywhere else on their computer in all the Mac applications. It’s a benefit that buttons work as expected, consistent with other buttons on the Mac, and don't pull the focus away from the text field you are already typing in. That does not appear to happen in Safari. I've made a codepen to hopefully illustrate my point: https://codepen.io/andy-blum/pen/ExXgxWO Clicking into a text input raises the following events: - mousedown - focus - focusin - mouseup - click Then, clicking into a directly adjacent button: - mousedown (button) - blur (input) - focusout (input) - mouseup (button) - click (button) After clickign the button, where is the focus? The tabbing order is maintained, but the focus leaves both the input and button. document.activeElement is the page's body, but I'm pretty sure that's the default when the focusoutEvent.relatedTarget == null. The reason I came across this bug recently was an issue for a search component listening for focusout events to close the type-ahead suggestions. Clicking the search button on this form closes the results and interrupts the submission of the form because the entire component loses focus before the button can even be clicked.
It’s possible that this behavior was required to make websites work--may require some research to find out. But pulling focus away when you push a button, something that does not happen on Mac outside web browsers, dilutes the value of macOS WebKit sticking with focus behavior that matches the rest of the Mac platform. Would be good to fix this. Or we may find that as requested in bug 22261 we should just go full-Windows-style-focus even on Mac as many other browsers did.
Regarding this topic, and as part of the discussion around :focus-visible and WebKit [*], there was an idea to give web authors the possibility to mark an element as non-focusable (in order to mimic Mac's behavior): > For authors who want a control that participates in the tab focus cycle, but without drawing a focus ring on tap or click, [a better solution may be] to give them a way to make elements keyboard-focusable but not mouse-focusable. I don’t think there’s any support in the web platform for that, although the opposite is possible with tabindex="-1". [*] https://github.com/WICG/focus-visible/issues/257#issue-894585219
<rdar://problem/82941778>
Cross linking this to https://www.drupal.org/project/drupal/issues/3269716 (this issue is the root of that issue)
If anyone stumbles across this issue because you've got a situation where focusout on button click is triggering some javascript, you can use tabindex to catch the "dropped" focus. Codepen: https://codepen.io/andy-blum/full/PoEzOwB
This is kind of duplicate of bug #112968.
^ It's true that this is a duplicate of https://bugs.webkit.org/show_bug.cgi?id=112968 in that the underlying issue appears to be the same. But it seems that that issue mostly considers the implications for visual focus indicators, which is not the only symptom of the underlying issue (as noted here, the issue is also problematic for anyone trying to monitor focus as a means of controlling UI). Tangentially, one thing that's interesting (to me, at least) is that the loss of focus that comes from clicking on a button does NOT necessarily cause the Selection to be lost in `contenteditable` nodes the way focus transitions usually do in WebKit (but shouldn't; see https://bugs.webkit.org/show_bug.cgi?id=224570).
It's not that it drops focus entirely, but it focuses it the nearest focusable ancestor, which is actually even worse. If you have a `<main tabindex="-1">` for example that is focused as you navigate your SPA, `<main>` will receive focus from the button elements. Otherwise it falls back to `<body>`. Here's a simple example: https://codepen.io/stowball/pen/gOrMowN
This bug also affects non-keyboard-focusing <input> types like checkboxes. Safari 17.2.1 (Mac) allows a partial workaround: If `tabindex` is explicitly set on the element being clicked, focus is not pulled away. I think this is the same fix mentioned in bug 112968, comment 12. This is natural enough for buttons, but anything with a <label> requires adding `tabindex` to the <label> as well, which is odd at best.