W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2012

[Bug 17541] New: Carefully think through how Range.insertNode should behave when the node to be inserted is already at the beginning of the range

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 Jun 2012 07:02:53 +0000
To: www-dom@w3.org
Message-ID: <bug-17541-4009@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17541

           Summary: Carefully think through how Range.insertNode should
                    behave when the node to be inserted is already at the
                    beginning of the range
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: ASSIGNED
          Severity: minor
          Priority: P2
         Component: DOM
        AssignedTo: ayg@aryeh.name
        ReportedBy: ayg@aryeh.name
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org


Test-case:

data:text/html,<!doctype html>
<p>abcd</p>
<script>
var range = document.createRange();
// Collapse range between "ab" and "cd"
range.setStart(document.body.firstChild.firstChild, 2);
range.insertNode(range.startContainer);
document.body.textContent =
range.startContainer.nodeName + " " +
range.startContainer.nodeValue + " " +
range.startOffset + " " +
range.endContainer.nodeName + " " +
range.endContainer.nodeValue + " " +
range.endOffset;
</script>

The spec appears to require "P null 0 P null 2", and this is what Firefox
16.0a1 does.  Chrome 21 dev throws HierarchyRequestError.  Opera Next 12.00
alpha gives "P null 0 #text cd 0".  IE10 Developer Preview gives "#text ab 0 P
null 2".  Or in pictures:

  Spec, Firefox: {abcd}
  Opera:         {ab]cd
  IE:            [abcd}

On reflection, the spec/Firefox behavior does make the most sense given what
the user asked for.  But this is a complete coincidence -- basically we have
two spec bugs combining to cancel out.  On the one hand we're splitting the
node the user asked to insert, so really now we're only inserting half of it. 
But on the other hand, the computation for "new offset" doesn't account for the
fact that we're not actually inserting a node that wasn't already there, so it
incorrectly adds one to the offset and puts the end after the reference node
(when it was supposed to be before).  So in the end we actually include the
whole node that we were asked to insert -- it's just split.

This is kind of amusing, but it does indicate that the algorithm needs more
thought.  At the very least, a note needs to alert the reader to these
subtleties.  I discovered it when I was fixing
<https://bugzilla.mozilla.org/show_bug.cgi?id=765799>, and I initially tried to
do so by substituting a different algorithm that didn't use indexOf() at all. 
Which failed in this case.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 19 June 2012 07:02:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:09 GMT