Re: cloneNode() and script execution

Aside from the fact that this sounds like a really bad idea (cloning a
script node), what behavior makes sense?

1)  Should the serialized document evaluate to the same web page (or as near
as possible) as the original page? If so then the cloned script node should
be executed. (Note that I am *not* pleased with this notion.)

2)  If the contents of the script node is mainly definitions (global
functions and objects to be used later), then re-executing the
script-fragment is wasteful, but not necessarily harmful. (Though shared
closures and identity tests may no longer work as expected.)

3)  If the contents of the script node is run-once code, then the script in
the cloned node would be run again, in a somewhat-different context. This
usage almost (but not really) makes sense. Since script is calling
cloneNode(), the same script could more easily simply make a function call.

If the *cloneNode()* method is executed on an ancestor of the *script* node,
what does this mean?

Copying a script node without executing the contained script fragment, how
can this make sense? Why do the copy?

Copying a script node, from script, instead of simply making a function call
- how can this make sense?

If you change the *src* attribute on a script node, should the new script be
executed. *Yes - otherwise, why bother?

*If you change the *text* attribute on a script node, should the new script
be executed. *Yes - otherwise, why bother?*

The program-semantics of a script node inserted (by script) are not
identical to the semantics of a script node occurring in the same place in
the initially loaded document.

*None of the solutions are going to be ideal in all use-cases.*

My take is that the cloned script node should NOT copy the script text.
1.  The serialized document is a little more likely to re-render as the same
web page.
2.  If the script author truly wants a copy of the existing script, they can
assign the *text* attribute. (Not likely, this.)
3.  If the *cloneNode()* method was invoked on an ancestor to the script
node, unwanted side effects are less likely.

I do not think there is a (good) valid use-case for copying the script node,
and re-executing the original script text. There is much potential for harm.


On Sun, Jan 18, 2009 at 10:16 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

>
> Hallvord R. M. Steen wrote:
>
>> Here is another issue for Ian to ponder while working on the script
>> execution stuff:
>>
>> If you clone a script node and append the to the document, does it run?
>>
>
> Assuming this is a script node that already ran?  In Gecko we just copy the
> "node has run" flag when cloning, so if you createElement a <script>, set
> its src, then clone it, then insert both scripts in the document they'll
> both run.
>
>   From my naturally biased point of view I think Opera makes more sense - a
>> "deep" clone remembers that the script was already executed, a shallow
>> doesn't because it doesn't clone the script code.
>>
>
> Here's what the DOM spec says about the "deep" argument to cloneNode [1]:
>
>  deep of type boolean
>    If true, recursively clone the subtree under the specified node;
>    if false, clone only the node itself (and its attributes, if it
>    is an Element).
>
> So I don't see how "because it doesn't clone the script node" can possibly
> be supported by the spec text here.  Certainly if the script is one loaded
> via @src it's cloning all the information there is to clone.
>
> I agree that the spec is not clear on what cloning should do with state not
> represented in attributes, but what it sounds like to me is that Opera (and
> Gecko, for that matter) added a hack to work around pages that broke because
> of assuming the IE behavior and Opera just added a slightly different hack
> than Gecko.  Nothing wrong with that, but let's not try to invent post-facto
> justifications.
>
> For what it's worth, https://bugzilla.mozilla.org/show_bug.cgi?id=127016is the Gecko bug that led to the current Gecko behavior, so I can in fact
> say with confidence that my description above of why Gecko behaves the way
> it does is correct.  ;)
>
> -Boris
>
> [1]
> http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-3A0ED0A4
>
>