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.
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.
Status: NEW → RESOLVED
Last Resolved: 13 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.