RESOLVED DUPLICATE of bug 145212 15921
Changing a Range should change a Selection previously set to this Range 
https://bugs.webkit.org/show_bug.cgi?id=15921
Summary Changing a Range should change a Selection previously set to this Range
Alexey Proskuryakov
Reported 2007-11-09 07:26:13 PST
In Firefox, any change to the range automatically changes the selection. Not so in WebKit. Of course, our implementation of addRange() already deviates from Firefox original a lot, because we don't support disjoint selections.
Attachments
test case (320 bytes, text/html)
2007-11-09 07:26 PST, Alexey Proskuryakov 		no flags
Details
JS for test case (ignore the PASS/FAIL values) which shows FF's screwy behavior (9.17 KB, application/x-javascript)
2009-02-11 16:47 PST, Eric Seidel (no email) 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2007-11-09 07:26:38 PST
Created attachment 17155 [details] test case
Alexey Proskuryakov
Comment 2 2007-11-09 08:02:55 PST
If this is fixed, then it will make sense to implement Selection.removeRange(), which unbreaks the link.
Alexey Proskuryakov
Comment 3 2009-02-11 08:19:40 PST
*** Bug 23885 has been marked as a duplicate of this bug. ***
Eric Seidel (no email)
Comment 4 2009-02-11 16:42:04 PST
Ok, I've investigated Gecko's Selection more closely. Attaching a test case in a minute. FF's getRangeAt(x) functions on live range objects (as we knew already). When addRange(range) is called, a range is appended to the range list. The range list is kept sorted first by document order of the start positions, then by length of the ranges. The focus and anchor are set to the start/end of the last range added. If the last range added would be sorted to somewhere other than the end of the list, it still becomes the new focus/anchor. If that range is later removed, then the last sorted range in the range list becomes the new focus/anchor. I think we want to design our own API. This one seems kinda screwy to me.
Eric Seidel (no email)
Comment 5 2009-02-11 16:47:14 PST
Created attachment 27579 [details] JS for test case (ignore the PASS/FAIL values) which shows FF's screwy behavior note that the PASS/FAIL values for this test do not correspond to any browser or desired behavior. I have just been using this to test what FF/WebKit do, and planned to update it to match the desired behavior if we chose to match FF's Selection API, which I don't think we really should do.
Kent Tamura
Comment 6 2017-07-03 01:48:45 PDT
Chromium fixed this.
Danilo
Comment 7 2019-04-16 06:05:07 PDT
This is probably a duplicate of https://bugs.webkit.org/show_bug.cgi?id=145212, right? (This ticket is older than 145212, but that other issue describes the root issue more clearly.)
Carlos Alberto Lopez Perez
Comment 8 2020-02-17 15:10:26 PST
(In reply to Danilo from comment #7) > This is probably a duplicate of > https://bugs.webkit.org/show_bug.cgi?id=145212, right? (This ticket is older > than 145212, but that other issue describes the root issue more clearly.) I also think its the same issue. Let's close this as duplicate even if its older for what you comment (more clearly described on the other bug) *** This bug has been marked as a duplicate of bug 145212 ***
Note You need to log in before you can comment on or make changes to this bug.