Bug 145212

Summary: selection.getRangeAt(0) should return a reference to the range, not a copy
Product: WebKit Reporter: Michał Gołębiowski-Owczarek <m.goleb+bugzilla>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ahmad.saleem792, ap, cdumez, clopez, db, enrica, karlcow, megan_gardner, rniwa, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: BrowserCompat, InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=216325
Attachments:
Description Flags
Testcase to reproduce the issue none

Michał Gołębiowski-Owczarek
Reported 2015-05-20 10:41:44 PDT
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.
Attachments
Testcase to reproduce the issue (1.27 KB, text/html)
2019-04-16 06:12 PDT, Danilo 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2015-05-20 11:17:58 PDT
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
Comment 2 2015-09-22 23:04:28 PDT
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
Comment 3 2015-09-22 23:05:45 PDT
<rdar://problem/22815169>
Danilo
Comment 4 2019-04-16 06:02:23 PDT
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
Comment 5 2019-04-16 06:03:28 PDT
By the way, here is the current version of the spec: https://w3c.github.io/selection-api/#dom-selection-getrangeat
Michał Gołębiowski-Owczarek
Comment 6 2019-04-16 06:05:45 PDT
Chrome used to have the same issue but it no longer does. Chrome 73 passes the test case from the initial post.
Danilo
Comment 7 2019-04-16 06:12:11 PDT
Created attachment 367531 [details] Testcase to reproduce the issue
Ryosuke Niwa
Comment 8 2019-04-16 21:13:16 PDT
*** Bug 160676 has been marked as a duplicate of this bug. ***
Carlos Alberto Lopez Perez
Comment 9 2020-02-17 15:06:58 PST
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
Comment 10 2020-02-17 15:10:26 PST
*** Bug 15921 has been marked as a duplicate of this bug. ***
Ryosuke Niwa
Comment 11 2020-02-18 21:43:58 PST
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
Comment 12 2020-09-24 23:33:46 PDT
Looks like Darin is going to fix this in https://bugs.webkit.org/show_bug.cgi?id=216325
Ahmad Saleem
Comment 13 2023-02-06 13:04:27 PST
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
Comment 14 2023-02-06 13:11:58 PST
*** This bug has been marked as a duplicate of bug 216325 ***
Note You need to log in before you can comment on or make changes to this bug.