selection.getRangeAt(0) should return a reference to the range, not a copy

• Component: DOM
• Status: RESOLVED DUPLICATE

[Michał Gołębiowski-Owczarek]

Steps to reproduce the problem:
1. Select some text on any page.
2. Open DevTools, go to the console
3. Enter:

var selection = getSelection();
selection.getRangeAt(0) === selection.getRangeAt(0);

It returns false. The spec:
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-getrangeat
is clear:
"it must return a reference to (not a copy of) the context object's range."

The same happens in Chrome; Firefox does the right thing.

[Alexey Proskuryakov]

Range support is quite limited in WebKit in a lot of ways, I'm not sure if we'll ever try to fix this particular aspect.

[Chris Dumez]

Ryosuke, what do you think about this? I see that you are the spec editor :)

FYI, this is causing many failures in the following W3C DOM test:
imported/w3c/web-platform-tests/dom/ranges/Range-mutations.html

[Radar WebKit Bug Importer]

<rdar://problem/22815169>

[Danilo]

I came across this problem when implementing a text editor. The spec clearly says that a reference should be returned, not a copy, so Safari does not implement getRangeAt in a compliant way.

A workaround is to modify the returned range, to remove the existing selection ranges and to re-add the modified range to the DOM. But that's quite an inefficient way of working with selections and ranges.

[Danilo]

By the way, here is the current version of the spec: https://w3c.github.io/selection-api/#dom-selection-getrangeat

[Michał Gołębiowski-Owczarek]

Chrome used to have the same issue but it no longer does. Chrome 73 passes the test case from the initial post.

[Danilo]

Created attachment 367531 [details]
Testcase to reproduce the issue

[Ryosuke Niwa]

*** Bug 160676 has been marked as a duplicate of this bug. ***

[Carlos Alberto Lopez Perez]

I was checking the many failures of WebKit on the WPT "selection/" tests and it seems most of them are related with this bug.

https://wpt.fyi/results/selection?label=master&product=chrome%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&product=webkitgtk&aligned&q=%28safari%3A%21pass%26safari%3A%21ok%29%20%28chrome%3Apass%7Cchrome%3Aok%29%20%28firefox%3Apass%7Cfirefox%3Aok%29

"selection.addRange(foo)" on WebKit doesn't set the selection range by a reference to "foo" (against the spec). So then the tests fail to assert that the range of the selection its the same range object added with addRange(), or that it has the expected properties. Example: http://wpt.live/selection/addRange.htm

[Carlos Alberto Lopez Perez]

*** Bug 15921 has been marked as a duplicate of this bug. ***

[Ryosuke Niwa]

Indeed! This will fix many WPT failures. However, this will require a massive engineering effort, and at the end of the day, it's probably not the most important compatibility bug since virtually all rich text editor in production works around this behavior difference already.

[Ryosuke Niwa]

Looks like Darin is going to fix this in https://bugs.webkit.org/show_bug.cgi?id=216325

[Ahmad Saleem]

Attached testcase seems to work fine now on WebKit ToT (259906@main) after Selection API - Live Ranges and update selection to move caret in between 'b' and 'c' as expected.

Can we close this as "RESOLVED CONFIGURATION CHANGED"? Thanks!

[Ryosuke Niwa]

*** This bug has been marked as a duplicate of bug 216325 ***