752231 - importNode deactivates content of script elements in svg documents

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Lukas Laag]

Attachment: ffclonescript.html

User Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

I am writing a program which lets the user pick SVG files with the file API and them to the current page. To do that, I use DOMParser.parseFromString, then Document.importNode. The attach sample reproduces my use case with a circle and a click handler.


Actual results:

If the SVG file contains <script> elements, these scripts fail to work in the imported SVG elements. Under Firebug, I get 'click is not defined'


Expected results:

The <script> elements should continue to work. I also tested with Chromium and Opera and they seem no to have this problem.

Comment 1

[Boris Zbarsky [:bzbarsky]]

It's not importNode that does this.  It's inserting a <script> element into a document, which is done by parseFromString in your case.

Henri, what's the right behavior here per spec?

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to Boris Zbarsky (:bz) from comment #1)
> Henri, what's the right behavior here per spec?

The right behavior is that parseFromString marks scripts unexecutable. The spec even has a note that recounts the consequences of the normative text: "script elements get marked unexecutable and the contents of noscript get parsed as markup."

The right behavior for cloning is to clone the "already started" flag:
http://www.whatwg.org/specs/web-apps/current-work/#already-started

Firefox is working as designed and per spec. Resolving INVALID in the sense that the allegation of actual behavior is true but the actual behavior is not a defect.

I guess bugs need to be filed on WebKit and Opera if they revive scripts in this case.

Comment 3

[Boris Zbarsky [:bzbarsky]]

For what it's worth, it looks like Opera and WebKit fail this for HTML <script> too.  And for innerHTML as well, not just for DOMParser.

I filed https://bugs.webkit.org/show_bug.cgi?id=86376 

Filing a bug on Opera is too painful; I'm not going to worry about it.

Comment 4

[Lukas Laag]

I copied your bug report in the Opera bug tracking system. I am not an Opera developer or partner, so I used their "wizard", which generated a bug ID (DSK-363698) in an automated email reply. Hopefully someone will look at it but since the bug tracking system is not public, I as an Opera outsider cannot follow the progress. 

Thanks anyway for the thorough and prompt answer (as usual)

Comment 5

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I poked jgraham about the Opera bug, and he said he could get it fixed.

Comment 6

[Lukas Laag]

I tested IE9/10 and it fails the test too. I have not filed the bug with MS though, I do not have the required Windows Live ID (whatever that is)

Comment 7

[Lukas Laag]

I downloaded the latest Windows8 preview and did more tests (my first tests were done on IE9 and an early IE10 platform preview). Good news: it turns out MS has fixed the problem and IE10 now executes Boris's testcase correctly.