Closed Bug 220157 Opened 21 years ago Closed 19 years ago

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


(Core :: DOM: Selection, defect)

Windows 2000
Not set





(Reporter: martijn.martijn, Assigned: mjudge)




(1 file)

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

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

Expected Results:  
Show the two different selections.

Testcase coming up.
Ever confirmed: true
Selection issue; the range stuff here is clearly ok.
Assignee: anthonyd → mjudge
Component: DOM Traversal-Range → Selection
QA Contact: ian → pmac
I attached a patch for bug 181105 which also fixes this.
*** Bug 252186 has been marked as a duplicate of this bug. ***
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.
Closed: 19 years ago
Resolution: --- → WORKSFORME
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?
You need to log in before you can comment on or make changes to this bug.