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

Re: [dom] The "replace" algorithm doesn't deal with the case when child == node.prevSibling

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sun, 3 Jun 2012 11:08:38 +0200
Message-ID: <CADnb78gsPz3eUgeMu5azuLhtaHoYqCzAfJEVgVWU_s1Cd9MNQw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-dom@w3.org
On Sat, Jun 2, 2012 at 4:59 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Perhaps what should happen is that in step 6.5 if "reference child" is set
> to "node" it should be set to node.nextSibling?  What do UAs do?

That seems to be what UAs do. My test was:

<!DOCTYPE html>.<script>
alert(document.documentElement.replaceChild(document.body,
document.head)) </script>


> P.S.  Actually,
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-pre-insert
> has a similar problem when "node" == "child".  Step 6 removes "node" (and
> hence "child") from "parent".  Step 7 tries to "Insert node into parent
> before child", but it's not clear how that's supposed to work in that
> situation.  Again, using a reference child which is child unless child ==
> node, in which case it's child.nextSibling should probably fix the
> situation.

I also fixed this using the same logic.

https://bitbucket.org/ms2ger/dom-core/changeset/506744df239c

Thanks a lot for catching this!


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/
Received on Sunday, 3 June 2012 09:09:07 GMT

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