Bug 224570 – Selection ranges removed whenever focus changes

• Component: HTML Editing
• Status: RESOLVED WONTFIX

[Ben Cronin]

Whenever focus leaves a contenteditable node, the `window.document`'s `Selection` object removes the `Range` that had been associated with it. For example, when focus moves from the contenteditable region to a button in https://jsfiddle.net/f2bqw1mt/3/, you can see in the console logs that the selection no longer has the range it once did.

This runs counter to expectations from the current specification: According to https://w3c.github.io/selection-api/#definition, "Once a selection is associated with a given range, it must continue to be associated with that same range until this specification requires otherwise." In particular, in https://w3c.github.io/selection-api/#user-interactions, it is stated that "The user agent must not make a selection empty if it was not already empty in response to any user actions (e.g. clicking on a non-editable region)."

For consistency with the spec and with behavior in other browsers, the selection should remain unchanged if only the `activeElement` changes. (And while it is true that the spec is labeled as a draft, but it is quite clear on this particular issue.)

[Ryosuke Niwa]

This is working as intended. In WebKit focus & selection stay in sync on purpose. We should probably fix the spec instead.

[Ben Cronin]

Created attachment 426473 [details]
Example of native app persistent selection as focus moves

[Ben Cronin]

"In WebKit focus & selection stay in sync on purpose. We should probably fix the spec instead."

How was this determined to be the desired behavior? Again, WebKit appears to be the outlier here in terms of how it implements the spec (all other browser engines I've been able to test do not remove ranges when moving focus). Additionally, in the few native apps I'm able to move focus to/from an editable field by keyboard, selection is maintained when focus moves. I've attached an example from Word (I couldn't find a built-in Mac app, e.g., Notes, where focus could be intuitively moved via keyboard), which reflects behavior that seems ideal and consistent with all experiences other than WebKit.

[Ryosuke Niwa]

(In reply to Ben Cronin from comment #3)
> "In WebKit focus & selection stay in sync on purpose. We should probably fix
> the spec instead."
> 
> How was this determined to be the desired behavior?

This is to match the behavior of the underlying platform on macOS.

> Again, WebKit appears to
> be the outlier here in terms of how it implements the spec (all other
> browser engines I've been able to test do not remove ranges when moving
> focus). Additionally, in the few native apps I'm able to move focus to/from
> an editable field by keyboard, selection is maintained when focus moves.

That is Windows / Linux behavior.

[Ben Cronin]

Created attachment 426572 [details]
Another example of native app persistent focus as selection moves (Notes.app)

[Ben Cronin]

> This is to match the behavior of the underlying platform on macOS.

Is this behavior documented/defined anywhere? I just tried out Notes.app and it seems that clicking within the app to move focus away from the editable field does not destroy the existing range on the field. This is admittedly slightly different, but it does seem to suggest that the native behavior is for selection to be maintained.

[Ben Cronin]

I wanted to check back in on this in light of https://bugs.webkit.org/show_bug.cgi?id=224570#c6.

Again, WebKit seems to have unique behavior here that presents challenges to developers who want to achieve consistent behavior for contenteditable regions across browsers. The spec is fairly clear on what the behavior should be and I'm also not seeing how the WebKit behavior truly matches native MacOS behavior.

Furthermore, the suggestion that spec should be rewritten to match what WebKit does seems to run counter to the Priority of Constituencies principle: https://www.w3.org/TR/html-design-principles/#priority-of-constituencies. In particular: 
* Under the WebKit implementation, if authors want to maintain selection across focus changes (both for consistency with other platforms and for the convenience of users), they now face the burden of maintaining additional state to track the selection.
* Conversely, if the default user agent behavior were to maintain selection but an author (for some reason) wanted to have it cleared when focus changes, they could achieve that behavior with comparatively less overhead. 

Given that "costs or difficulties...to the author should be given more weight than costs to implementors," there seems to be a clear case for preserving the latter behavior, which is the current spec and the behavior implemented by other browsers.