| 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: | P3 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
|
Description
Alexey Proskuryakov
2007-11-09 07:26:13 PST
Created attachment 17155 [details]
test case
If this is fixed, then it will make sense to implement Selection.removeRange(), which unbreaks the link. *** Bug 23885 has been marked as a duplicate of this bug. *** 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. 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.
Chromium fixed this. 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.) (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 *** |