145212 2015-05-20 10:41:44 -0700 selection.getRangeAt(0) should return a reference to the range, not a copy 2023-02-06 13:11:58 -0800 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 216325 https://bugs.webkit.org/show_bug.cgi?id=216325 BrowserCompat, InRadar P2 Normal --- 1 m.goleb+bugzilla webkit-unassigned ahmad.saleem792 ap cdumez clopez db enrica karlcow megan_gardner rniwa webkit-bug-importer wenson_hsieh oldest_to_newest 1096284 0 m.goleb+bugzilla 2015-05-20 10:41:44 -0700 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. 1096298 1 ap 2015-05-20 11:17:58 -0700 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. 1128230 2 cdumez 2015-09-22 23:04:28 -0700 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 1128231 3 webkit-bug-importer 2015-09-22 23:05:45 -0700 <rdar://problem/22815169> 1527716 4 db 2019-04-16 06:02:23 -0700 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. 1527717 5 db 2019-04-16 06:03:28 -0700 By the way, here is the current version of the spec: https://w3c.github.io/selection-api/#dom-selection-getrangeat 1527720 6 m.goleb+bugzilla 2019-04-16 06:05:45 -0700 Chrome used to have the same issue but it no longer does. Chrome 73 passes the test case from the initial post. 1527721 7 367531 db 2019-04-16 06:12:11 -0700 Created attachment 367531 Testcase to reproduce the issue 1528004 8 rniwa 2019-04-16 21:13:16 -0700 *** Bug 160676 has been marked as a duplicate of this bug. *** 1619922 9 clopez 2020-02-17 15:06:58 -0800 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 1619924 10 clopez 2020-02-17 15:10:26 -0800 *** Bug 15921 has been marked as a duplicate of this bug. *** 1620539 11 rniwa 2020-02-18 21:43:58 -0800 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. 1691794 12 rniwa 2020-09-24 23:33:46 -0700 Looks like Darin is going to fix this in https://bugs.webkit.org/show_bug.cgi?id=216325 1931467 13 ahmad.saleem792 2023-02-06 13:04:27 -0800 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! 1931470 14 rniwa 2023-02-06 13:11:58 -0800 *** This bug has been marked as a duplicate of bug 216325 *** 367531 2019-04-16 06:12:11 -0700 2019-04-16 06:12:11 -0700 Testcase to reproduce the issue selection-testcase.html text/html 1303 db PCFkb2N0eXBlIGh0bWw+CjxodG1sPgogICAgPGhlYWQ+CiAgICAgICAgPHRpdGxlPlNlbGVjdGlv biBCdWc8L3RpdGxlPgogICAgICAgIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+CiAgICAgICAgICAj d3JhcHBlciB7IGJvcmRlcjogMXB4IHNvbGlkIGJsdWU7IH0KICAgICAgICA8L3N0eWxlPgogICAg PC9oZWFkPgogICAgPGJvZHk+CiAgICAgICAgPGRpdiBpZD0id3JhcHBlciIgY29udGVudGVkaXRh YmxlPmFiYzwvZGl2PgogICAgICAgIDxidXR0b24gaWQ9ImNyZWF0ZSI+Q3JlYXRlIHNlbGVjdGlv bjwvYnV0dG9uPgogICAgICAgIDxidXR0b24gaWQ9InVwZGF0ZSI+VXBkYXRlIHNlbGVjdGlvbjwv YnV0dG9uPgogICAgICAgIDxwPkNsaWNraW5nIHRoZSBmaXJzdCBidXR0b24gc2hvdWxkIGNyZWF0 ZSBhIHNlbGVjdGlvbiBiZXR3ZWVuIGEgYW5kIGIuCiAgICAgICAgQ2xpY2tpbmcgdGhlIHNlY29u ZCBidXR0b24gc2hvdWxkIHVwZGF0ZSB0aGUgc2VsZWN0aW9uIGFuZCBtb3ZlIHRoZQogICAgICAg IGNhcmV0IGJldHdlZW4gYiBhbmQgYy48L3A+CiAgICA8c2NyaXB0PgogICAgICAgIGNvbnN0IHdy YXBwZXIgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgid3JhcHBlciIpOwoKICAgICAgICBkb2N1 bWVudC5nZXRFbGVtZW50QnlJZCgiY3JlYXRlIikuYWRkRXZlbnRMaXN0ZW5lcigiY2xpY2siLCAo ZSkgPT4gewogICAgICAgICAgY29uc3Qgc2VsID0gZG9jdW1lbnQuZ2V0U2VsZWN0aW9uKCk7CiAg ICAgICAgICBjb25zdCByYW5nZSA9IGRvY3VtZW50LmNyZWF0ZVJhbmdlKCk7CiAgICAgICAgICBj b25zdCB0ZXh0ID0gd3JhcHBlci5jaGlsZE5vZGVzWzBdOwogICAgICAgICAgcmFuZ2Uuc2V0U3Rh cnQodGV4dCwgMSk7CiAgICAgICAgICByYW5nZS5jb2xsYXBzZSh0cnVlKTsKICAgICAgICAgIHNl bC5yZW1vdmVBbGxSYW5nZXMoKTsKICAgICAgICAgIHNlbC5hZGRSYW5nZShyYW5nZSk7CiAgICAg ICAgfSk7CgogICAgICAgIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJ1cGRhdGUiKS5hZGRFdmVu dExpc3RlbmVyKCJjbGljayIsIChlKSA9PiB7CiAgICAgICAgICBjb25zdCBzZWwgPSBkb2N1bWVu dC5nZXRTZWxlY3Rpb24oKTsKICAgICAgICAgIGNvbnN0IHJhbmdlID0gc2VsLmdldFJhbmdlQXQo MCk7CiAgICAgICAgICBjb25zdCB0ZXh0ID0gd3JhcHBlci5jaGlsZE5vZGVzWzBdOwogICAgICAg ICAgcmFuZ2Uuc2V0U3RhcnQodGV4dCwgMik7CiAgICAgICAgICByYW5nZS5jb2xsYXBzZSh0cnVl KTsKICAgICAgICB9KTsKICAgIDwvc2NyaXB0PgogICAgPC9ib2R5Pgo8L2h0bWw+Cg==