Closed Bug 752231 Opened 12 years ago Closed 12 years ago

importNode deactivates content of script elements in svg documents


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

12 Branch
Not set





(Reporter: laaglu, Unassigned)




(1 file)

Attached file 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.
OS: Linux → All
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?
(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:

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.
Closed: 12 years ago
Resolution: --- → INVALID
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 

Filing a bug on Opera is too painful; I'm not going to worry about it.
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)
I poked jgraham about the Opera bug, and he said he could get it fixed.
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)
Attachment #621309 - Attachment mime type: text/plain → text/html
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.
You need to log in before you can comment on or make changes to this bug.