The spec says "If the start boundary point of the Range is in a Text node, the insertNode operation splits the Text node at the boundary point." Mozilla doesn't handle this correctly, we don't split the text node but instead try to append the new node to the text node, which of course always fails.

Unfortunately, the problem is not just that the text node is not split, but that nsRange::insertNode() is broken in just about every conceivable way. http://lxr.mozilla.org/seamonkey/source/content/base/src/nsRange.cpp#2059 2073 if( (nsIDOMNode::CDATA_SECTION_NODE == tNodeType) || 2074 (nsIDOMNode::TEXT_NODE == tNodeType) ) Should be checking type of tStartContainer, not type of node to be inserted. 2081 return tSCParentNode->InsertBefore(aN, tSCParentNode, getter_AddRefs(tResultNode)); 1) Need to splitText if necessary (see SurroundContents for details) 2) Second arg should be tStartContainer, so we don't try to insert before self. 2092 if(tStartOffset == (PRInt32)tChildListLength) Comparison shouldn't be necessary. tChildList->Item() should return null if offset greater than tChildListLength, and tStartContainer->InsertBefore reverts to append if tChildNode is null.

Here's another test case for range.insertNode()

taking

Comment on attachment 121596 [details] [diff] [review] Patch based on Nathan's suggestion Yay, nsRange!

Comment on attachment 121596 [details] [diff] [review] Patch based on Nathan's suggestion Requesting 1.4b approval; this is a simple change to bring us in line with the spec and prevent content disappearing completely when insertNode is used on ranges.

Comment on attachment 121596 [details] [diff] [review] Patch based on Nathan's suggestion a=asa (on behalf of drivers) for checkin to 1.4b

Fixed.