WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
224570
Selection ranges removed whenever focus changes
https://bugs.webkit.org/show_bug.cgi?id=224570
Summary
Selection ranges removed whenever focus changes
Ben Cronin
Reported
2021-04-14 12:39:06 PDT
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.)
Attachments
Example of native app persistent selection as focus moves
(1.81 MB, image/gif)
2021-04-19 13:58 PDT
,
Ben Cronin
no flags
Details
Another example of native app persistent focus as selection moves (Notes.app)
(551.38 KB, image/gif)
2021-04-20 11:19 PDT
,
Ben Cronin
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2021-04-15 15:44:53 PDT
This is working as intended. In WebKit focus & selection stay in sync on purpose. We should probably fix the spec instead.
Ben Cronin
Comment 2
2021-04-19 13:58:49 PDT
Created
attachment 426473
[details]
Example of native app persistent selection as focus moves
Ben Cronin
Comment 3
2021-04-19 14:00:01 PDT
"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
Comment 4
2021-04-19 20:38:20 PDT
(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
Comment 5
2021-04-20 11:19:56 PDT
Created
attachment 426572
[details]
Another example of native app persistent focus as selection moves (Notes.app)
Ben Cronin
Comment 6
2021-04-20 11:29:19 PDT
> 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
Comment 7
2021-04-26 12:02:08 PDT
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug