Closed
Bug 354009
Opened 19 years ago
Closed 13 years ago
Range.surroundContents() does not raise Exception for non-text nodes
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 454326
People
(Reporter: djmolny, Unassigned)
Details
(Keywords: qawanted, testcase)
Attachments
(1 file)
|
1.17 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060923 Firefox/3.0a1
(Problem initially observed on Firefox 1.5.0.7, replicated in 3.0a1.)
Reproducible: Always
Steps to Reproduce:
Load the following web page, click the hyperlink, and observe that the 'middle node' disappears:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
<script>
function snipIt() {
var startNode = document.getElementById("cutMeMick").childNodes[0]
var endNode = document.getElementById("stopHere").childNodes[0]
var r = document.createRange()
r.setStart(startNode, 43) // Yes, I counted the characters. Deal with it.
r.setEnd(endNode, 5)
var newSpan = document.createElement("span")
newSpan.className = "hilite"
r.surroundContents(newSpan.cloneNode(true))
}
</script>
<style TYPE="text/css">
.hilite {background-color:purple; color:white}
</STYLE>
</head>
<body>
<p>Click <a href="javascript:snipIt()">here</a> to split the DOM tree using surroundRange() and apply a new style. </p>
<hr />
<span><p id="cutMeMick">This is the first node. This is the future middle<p id="stopHere">node, created by a surroundRange() operation.<p class="hilite">This is the future final node, with same highlight style.</span>
</body>
</html>
Actual Results:
Text of the 'middle node' became white-on-white (invisible). Highlighting via mouse click-and-drag confirms that the text is still present.
Expected Results:
'middle node' should have displayed as white-on-purple. Note that the nodes that were not part of the surroundRange() operation display properly before and after the surroundRange() operation.
I would guess that surroundRange() method itself isn't the problem... the DOM Inspector shows a sane document after the <span> is inserted. I suspect that these particular circumstances are exercising a latent bug in the rendering logic. But hey, what do I know? :)
IMHO this is a fairly severe, but rare, bug.
|
||
Comment 2•19 years ago
|
||
As far as I can tell, this holds true in "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061120 Minefield/3.0a1".
Sorry, original bug report referenced (non-existent) Node.surroundRange() method, should have been Range.surroundContents().
Summary: Node.surroundRange() leads to incorrect rendering → Range.surroundContents() leads to incorrect rendering
Further research has indicated that my example is an illegal usage of Range.surroundContents() because the Range span includes non-text nodes. See:
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#Level-2-Range-Surrounding
However, that document also states that the method should raise an exception in that case, which it does not. Therefore I am leaving the bug open and changing the severity from 'normal' to 'minor'.
Severity: normal → minor
Summary: Range.surroundContents() leads to incorrect rendering → Range.surroundContents() does not raise Exception for non-text nodes
|
||
Comment 5•18 years ago
|
||
Is this bug still present with the latest trunk build?
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
If not, can you please close this bug as WORKSFORME. Thanks!
|
||
Comment 6•18 years ago
|
||
This is still present in trunk builds. For comparison, Opera 9.24 raises a RangeException with code = BAD_BOUNDARYPOINTS_ERR.
Status: UNCONFIRMED → NEW
Component: General → DOM: Traversal-Range
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → traversal-range
|
||
Updated•17 years ago
|
Whiteboard: CLOSEME 07/14
|
|
||
Comment 7•15 years ago
|
||
This appears to be fixed (Gecko/20100420), so this bug can be closed.
|
|
||
Comment 8•15 years ago
|
||
We should leave this bug open for now so we can verify it's the right
exception, and also add some regression tests.
It would be helpful to know exactly when it got fixed.
Andrew, can you bisect the nightly builds to see?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Flags: in-testsuite?
Keywords: qawanted
|
|
||
Comment 9•15 years ago
|
||
The exception does appear to be the correct one (but of course tests would be good).
Sorry, but I'm not willing to do a bisect.
Its often quickest to look at the history for the relevant files and do a bit of guesswork, but I work for another browser vendor (ANT Software) so I limit myself to the bug tracker and binaries. "Full disclosure" would have been good here, but unfortunately there isn't really a way to do that in bugzilla.
|
||
Comment 10•13 years ago
|
||
Bug 454326 was probably what fixed this, and it added tests. So I don't think this bug needs to remain open at this point.
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → DUPLICATE
|
Assignee | |
Updated•12 years ago
|
Component: DOM: Traversal-Range → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•