W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: cloneNode() and script execution

From: Hallvord R. M. Steen <hallvord@opera.com>
Date: Mon, 19 Jan 2009 15:26:44 +0900
To: "Boris Zbarsky" <bzbarsky@mit.edu>, "Preston L. Bannister" <preston@bannister.us>
Cc: public-html@w3.org
Message-ID: <op.unzquucra3v5gv@hr-opera.oslo.opera.com>

On Mon, 19 Jan 2009 03:16:06 +0900, Boris Zbarsky <bzbarsky@mit.edu> wrote:

>>  If you clone a script node and append the to the document, does it run?
> Assuming this is a script node that already ran?

Yes. Sorry I wasn't specific enough.

>>  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.

(snipped spec quote)

> So I don't see how "because it doesn't clone the script node" can  
> possibly be supported by the spec text here.

You actually misquoted me slightly - I wrote "script code", not "script  
node" - was that simply a typo or a misunderstanding?

In fact, Gecko does not AFAIK mark empty script elements with the "node  
has run" flag. Doing a shallow clone which creates an empty node might  
easily fall into that category.

> 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.

I'm not arguing that whichever implementation is supported by some weird  
reading of the spec - merely thinking aloud about what *makes sense*.  
Perhaps I came across as trying to accusse Gecko of a spec violation?? If  
so I apologise. That was absolutely not intended as the whole reason for  
writing the E-mail was to point out that this is unspecified in DOM2 / 3.

I hope I'm allowed to have opinions even if I work for a browser vendor  
though ;)

On Mon, 19 Jan 2009 10:28:14 +0900, Preston L. Bannister  
<preston@bannister.us> wrote:

> Aside from the fact that this sounds like a really bad idea (cloning a
> script node)

Yes, probably happens mostly by accident..

> , 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.)

If it is a goal (and if there are use cases for) being able to clone a  
document AND it's scripting environment/state, we should IMO add new  
methods for doing so.

..actually the only use case I've personally had for cloning entire  
documents was to keep the rest of the generated DOM and discard the  
scripts. I've got a bookmarklet or two for that :)

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

Probably mostly by accident. I know we've had problems with scripts that  
moved DOM fragments including scripts around in the DOM, because back then  
Opera wasn't close enough to what IE does when script nodes are moved. (As  
far as I remember IE does not re-execute scripts at all).

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

Not current practise according to my tests (except for Safari which  
happily re-executes many more scripts than the rest of us - perhaps Safari  
just didn't come across those compat problems yet? Pure luck? ;-) )

> My take is that the cloned script node should NOT copy the script text.

That would violate DOM specs if the argument to cloneNode() evaluates to  

> 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.

I agree.

Hallvord R. M. Steen
Core JavaScript tester, Opera Software
Opera - simply the best Internet experience
Received on Monday, 19 January 2009 06:27:04 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:41 UTC