Bug 15921

Summary:

Changing a Range should change a Selection previously set to this Range

Product:

WebKit

Reporter:

Alexey Proskuryakov <ap>

Component:

HTML Editing

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

alex, ayg, clopez, db, eric, jparent, michael.vm, ojan, syoichi, tkent

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
test case	none
JS for test case (ignore the PASS/FAIL values) which shows FF's screwy behavior	none

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.