Bug 24896 – REGRESSION: Range#collapsed is mis-reported after Range#extractContents is called

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: DOM

[Nick Santos]

Steps to repro:
1) Given the HTML <div>Some text</div>
2) Create a range that starts at offset 0 of the div and ends at the end of the text node.
3) call range.extractContents()

Expected result:
range.collapsed == true

Actual result:
range.collapsed == false

See
http://www.nick-santos.com/tests/range_test2.html
for an interactive test case.

Works on FF2/3, and WebKit 525.

Does not work on WebKit 528 and 530.

[Eric Seidel (no email)]

PassRefPtr<DocumentFragment> Range::processContents(ActionType action, ExceptionCode& ec)

is your culprit here.  That HUGE function is likely way-past buggy and needs to be split into smaller pieces.  But that aside, the fix here is just to check at the end if the ActionType was EXTRACT or DELETE and to update collapsed in that instance.

[Eric Seidel (no email)]

I think we need a test case here which outputs the what the start/end of the range are.

Since this used to work in WebKit, it's a regression and thus a P1.

[Eric Seidel (no email)]

I think this new behavior is correct.  A better test case would show that.

This test is selecting from [div, 0] to [text, last_offset], and then calling extract.  The spec says:

http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#Level-2-Range-Extracting
It is important to note that nodes that are partially selected by the Range are cloned. Since part of such a node's contents must remain in the Range's context tree and part of the contents must be moved to the new DocumentFragment, a clone of the partially selected node is included in the new DocumentFragment. Note that cloning does not take place for selected elements; these nodes are moved to the new DocumentFragment.

The text node is partially selected in our example.

Moreover the spec says:

Note that if deletion of a Range leaves adjacent Text nodes, they are not automatically merged, and empty Text nodes are not automatically removed. Two Text nodes should be joined only if each is the container of one of the boundary-points of a Range whose contents are deleted. To merge adjacent Text nodes, or remove empty text nodes, the normalize() method on the Node interface should be used.

[Eric Seidel (no email)]

Partially selected is defined here:
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#td-partially-selected

[Eric Seidel (no email)]

So we need a better test here, and need to find out what FF is doing differently.  Are they setting the selection to something different than we are?  Are they removing the empty text node?  Are they returning collapsed() == true for a range ([div,0],[text, 0])?  I expect that one of these is true, and that whichever one it is is the core bug here.  Once we understand what that behavior is we can decide if it's something which needs changing in WebKit, Gecko or the spec. ;)

[Julie Parent]

I'm working on better tests cases now ... will have answers for your shortly.

[Julie Parent]

For selecting (div, 0), (text, text.length):
WebKit reports the selection after extract contents as (div, 0), (text, 0), collapse: false, and the text node remains.
FF reports (div, 0), (div, 0), collapse: true, and the text node remains.

So, they agree with not removing the text node, but they are modifying the selection.

For selecting (div, 0), (div, 1):
Everyone agrees, after extractContents the selection is (div, 0), (div, 0), collapsed: true, no text node.

For selecting (text, 0), (text, text.length):
Everyone agrees, selection is (text, 0), (text, 0), collapsed:true, text node remains.

See http://jparent.googlepages.com/extractTests.html for the tests I ran.

Finally, no, Firefox does not report (div, 0), (text, 0) as collapsed.

[Nick Santos]

I think Gecko is doing the right thing here. From section 2.7:

The extractContents() method removes nodes from the Range's context tree similarly to the deleteContents() method. 

And from section 2.6:

After deleteContents() is invoked on a Range, the Range is collapsed. ...If a node was partially selected by the Range and was an ancestor container of the start of the Range and no ancestor of the node satisfies these two conditions, then the Range is collapsed to the position immediately after the node, as in examples (2) and (4).

[Alexey Proskuryakov]

Isn't this a duplicate of bug 24122, which is already fixed in ToT?

[Julie Parent]

Yeah, I think you are right about this being a duplicate, I just checked on a nightly and it is fixed.

*** This bug has been marked as a duplicate of 24122 ***