Bug 15921 - Changing a Range should change a Selection previously set to this Range
Summary: Changing a Range should change a Selection previously set to this Range
Status: RESOLVED DUPLICATE of bug 145212
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Normal
Assignee: Nobody
URL:
Keywords:
: 23885 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-09 07:26 PST by Alexey Proskuryakov
Modified: 2020-02-17 15:10 PST (History)
10 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 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.
Comment 1 Alexey Proskuryakov 2007-11-09 07:26:38 PST
Created attachment 17155 [details]
test case
Comment 2 Alexey Proskuryakov 2007-11-09 08:02:55 PST
If this is fixed, then it will make sense to implement Selection.removeRange(), which unbreaks the link.
Comment 3 Alexey Proskuryakov 2009-02-11 08:19:40 PST
*** Bug 23885 has been marked as a duplicate of this bug. ***
Comment 4 Eric Seidel (no email) 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.
Comment 5 Eric Seidel (no email) 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.
Comment 6 Kent Tamura 2017-07-03 01:48:45 PDT
Chromium fixed this.
Comment 7 Danilo 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.)
Comment 8 Carlos Alberto Lopez Perez 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 ***