1899020 - Selection.direction's value is incorrect

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Mozes Stumpf]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

Steps to reproduce:

Select a node and check the Selection.direction's value

Demo: https://codepen.io/IDontHaveAny/pen/bGywOwZ

Actual results:

If the Selection is collapsed, the direction is "forward"
On double click: it selects a word and the direction will be "none"

Expected results:

When the selection is collapsed, the direction is should be "none".

When selecting a word with double click, the selection should be "forward" because the anchor is before the focus.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Selection' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jan Jaeschke [:jjaschke]]

Hi Sean, didn’t you work on this during your shadow DOM selection work?

Comment 3

[Sean Feng [:sefeng]]

Attachment: Bug 1899020 - Make selection.direction returns none when the selection is collapsed

Comment 4

[Sean Feng [:sefeng]]

Thanks for the bug! I agree with one of the expected results.

When the selection is collapsed, the direction is should be "none".

This makes sense, the submitted patch is for fixing this.

When selecting a word with double click, the selection should be "forward" because the anchor is before the focus.

The selection API defines the direction based on how the selection was created by users. If the user makes a "forward" selection, it's "forward", and vise versa. For the double click case, the selection was indeed "directionless" because the user didn't make any direction, so it should return "none" in my opinion. It would be a spec issue if we want to change it.

Comment 5

[Mozes Stumpf]

The selection API defines the direction based on how the selection was created by users. If the user makes a "forward" selection, it's "forward", and vise versa.

Selection API documentation:

If the user creates a selection by indicating first one boundary point of the range and then the other, and the first indicated boundary point is after the second, then the corresponding selection must initially be backwards. If the first indicated boundary point is before the second, then the corresponding selection must initially be forwards. Otherwise, it must be directionless.

Based on the documentation, it only considers the direction based on the positions of the boundary-points.

For the double click case, the selection was indeed "directionless" because the user didn't make any direction, so it should return "none" in my opinion. It would be a spec issue if we want to change it.

Logically, there is no direction in the case of a double-click. Even though I have been working on a contenteditable project for a while, and I haven't seen any use case where it could be useful. I think the only useful case for direction would be to determine the direction of the boundary-points based on their positions.

Comment 6

[Sean Feng [:sefeng]]

But we are talking about the indicated boundary point and in this case the user makes both boundaries at the same location right? So I still think Firefox is doing what the spec says.

Regardless, this should be spec issue. Do you mind file one to https://github.com/w3c/selection-api to clarify?

Comment 7

[Mozes Stumpf]

I've opened one
https://github.com/w3c/selection-api/issues/177

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5b0b81142581
Make selection.direction returns none when the selection is collapsed r=jjaschke,dom-core

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/46518 for changes under testing/web-platform/tests

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 11

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/5b0b81142581