Should focus affect selection?

[annevk]

Chrome (and the standard) do not change the selection when focus changes. Firefox and Safari do.

Apart from the discussion what makes the most sense, is there precedent for this in OSs?

This has resulted in a compatibility issue for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1755215. Which prompted Karl to file https://bugs.chromium.org/p/chromium/issues/detail?id=1300132.

cc @rakina @dtapuska @rniwa @whsieh @emilio @karlcow

[rniwa]

On Apple platforms, there is no distinction between focus & selection. As such, we need to tie them together. On Windows, focus & selection are two distinct concepts so you can have a focus but not necessarily selection and vice versa.

[annevk]

Thanks, so the standard needs to allow for that in some way.

[domenic]

On Apple platforms, there is no distinction between focus & selection. As such, we need to tie them together.

This doesn't appear to be Apple platform-wide thing, but instead a choice Safari has made on Apple platforms. (The demo at https://bug1755215.bmoattachments.org/attachment.cgi?id=9263674 has separate selection and focus in Chrome on Apple platforms.)

We probably still want the spec to allow different user agents to make different decisions here, like we already do for, e.g., what controls are focusable.

[rniwa]

On Apple platforms, there is no distinction between focus & selection. As such, we need to tie them together.

This doesn't appear to be Apple platform-wide thing, but instead a choice Safari has made on Apple platforms. (The demo at https://bug1755215.bmoattachments.org/attachment.cgi?id=9263674 has separate selection and focus in Chrome on Apple platforms.)

Well, I'm saying this is the underlying platform / operating system convention. Whether any specific UA follows that convention or not is up to each UA. Safari tries to match the OS / platform convention as much as it can.

[emilio]

FWIW, I think in Gecko we also tie them together. I think not doing so is a bit weird, since keydown events and so get dispatched to the focused element... For example, why would a keydown event listener in a link prevent the user from copying a visible selection in a totally unrelated part of the page?

[masayuki-nakano]

There is an opposite case: https://bugzilla.mozilla.org/show_bug.cgi?id=1758441

<div contenteditable>.blur() causes selectionchange event on Chrome, but not on Safari and Firefox.

[MelSumner]

👋 weighing in with some ARIA info: https://www.w3.org/TR/wai-aria-practices-1.2/#kbd_focus_vs_selection

I think it explains rather well how focus and selection are different. 👍

[annevk]

@MelSumner I think the selection that is talking about is quite a bit different from text selection (as represented by the Selection object), which is what is under discussion here.