importNode deactivates content of script elements in svg documents

RESOLVED INVALID

Status

()

Core
DOM: Core & HTML
RESOLVED INVALID
6 years ago
3 years ago

People

(Reporter: Lukas Laag, Unassigned)

Tracking

12 Branch
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
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:
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: 6 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.
(Reporter)

Comment 4

6 years ago
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.
(Reporter)

Comment 6

6 years ago
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
(Reporter)

Comment 7

6 years ago
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.

Updated

3 years ago
Duplicate of this bug: 1101385
You need to log in before you can comment on or make changes to this bug.