220157 - Wrong selection display, with two ranges in the same textnode on the same line

Status: RESOLVED WORKSFORME

(Core :: DOM: Selection, defect)

Description

[Martijn Wargers (dead)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030917 Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030917 Firebird/0.6.1+

The visible representation of the selected objects is not right when there are
two range objects on the same line.
The whole line gets selected (at least that is what you see), instead of the two
ranges. The ranges stay intact, though.
What you see if you push the select 80-85 button also and then resize the window
a bit, you get strange characters at the end of the line. But if the 80-85
selection happens to be on the second line, the visible presentation of the
selection is all right.


Something similar happens with the surroundcontents function. You can't use the
surroundcontents function if the selection is only in one textnode, because of
bug 135928. You'll have to select at least the entire italic text or more and
then click on the surroundcontents(bold element) button. Then you'll see that
the visible representation of the selection is also wrong. You'll see that the
text before the real selection is being selected.
But maybe this should be filed as a different bug.

Reproducible: Always

Steps to Reproduce:
1.Click button 1
2.Click button 2
3.

Actual Results:  
The whole first line is selected (not really, but the first line is displayed as
selected)

Expected Results:  
Show the two different selections.

Testcase coming up.

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase to show the problem

Comment 2

[Boris Zbarsky [:bzbarsky]]

Selection issue; the range stuff here is clearly ok.

Comment 3

[Neil Deakin]

I attached a patch for bug 181105 which also fixes this.

Comment 4

[Neil Deakin]

*** Bug 252186 has been marked as a duplicate of this bug. ***

Comment 5

[Martijn Wargers (dead)]

It seems like this is fixed in current trunk builds :)
Doesn't work in 2005-01-31 trunk build.
Works in 2005-02-01 trunk build.

My guess is that this was fixed by the fix for bug 278312.

Comment 6

[Michael Bolin]

Yes, it seems like this is fixed in the current trunk build; however, it doesn't
seem to be fixed in the 1.0.2 release candidate -- how can I check to see when I
can expect this fix to make it into a public release?