Created attachment 621309 [details] 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.
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: 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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 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 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.
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.