[webkit-dev] DOM tree traversal on detached nodes

[Ryosuke Niwa]

On Wed, Jun 6, 2012 at 6:14 PM, Kentaro Hara <haraken at chromium.org> wrote:
>
> The behavior (b) is weird, and it causes other subtle issues. For example,
> editing. Consider the following code (test html<http://haraken.info/null/ref_count4.html>
> ):
>

In fact, it's probably not spec compliant as is because HTML/DOM
specification doesn't allow garbage collection to be observed by scripts
(credit: arv).

  <div contentEditable>
>   a<p>b<p>c<p>d<span id="span">e<br>f<br>g<br>h</p>i</p>j</p>k
>   </div>
>   </body>
>   <script>
>   span = document.getElementById("span");
>   setTimeout(function () {
>     // Please manually delete the texts in <div> within 10 seconds
>     alert("span = " + span);  // <span>
>     alert("span.parentNode = " + span.parentNode);  // <p>
>     alert("span.parentNode = " + span.parentNode.parentNode);  // null
>     alert("span.firstChild = " + span.firstChild);  // "e"
>   }, 10000);
>
> I am not sure why span.parentNode returns <p>
> but span.parentNode.parentNode returns null. Maybe an undo stack keeps
> reference to <p>?
>

Yes.

First of all, it seems that the behavior is not defined in the spec.
>

Yes but implied in that there are no parts of the spec that says we can
break references (credit: arv).

IMHO, (a) would be the best semantics. The semantics of (a) is very
> straightforward from the perspective of JS programmers, i.e. "Reachable DOM
> nodes from JS are kept alive". On the other hand, (b) and (c) are not good
> in that the semantics is UNDEFINED (i.e. the semantics depends on the
> implementation details). Consequently, in terms of the semantics, WebKit
> might want to change the current behavior to (a).
>
> That being said, I am not sure if the semantics is practically important
> in the real world. As explained above, indeed the behavior (b) will cause a
> lot of weird bugs, but it would be "rare" cases. In fact, considering that
> IE, FIrefox, Opera, Chrome and Safari has been behaving differently, the
> current confusing semantics has not caused a big practical issue. This
> would imply that the behavior does not matter in the real world. If you
> know any bugs caused by the behavior, I am super happy to know.
>

This behavior caused some security bugs to be introduced, etc... so it's
definitely worth fixing if possible. A practical problem, as Darin pointed
out, is that fixing this bug will most likely regress the performance of
WebKit and increases the memory usage because we won't be collecting nodes
as early as we do now.

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120606/6b29a2b4/attachment.html>