Bug 135698 - SVGElement has no innerHTML property
Summary: SVGElement has no innerHTML property
Status: RESOLVED DUPLICATE of bug 136903
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-07 05:12 PDT by Ophir LOJKINE
Modified: 2014-12-15 10:01 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ophir LOJKINE 2014-08-07 05:12:09 PDT
In webkit, we can't access the innerHTML of an inline <SVG> element in an html document.

Steps to reproduce:
In the console, type

'innerHTML' in SVGSVGElement.prototype 

Results:
On Firefox and Chrome: true
On webkit: false
Comment 1 Dirk Schulze 2014-08-07 06:09:49 PDT
(In reply to comment #0)
> In webkit, we can't access the innerHTML of an inline <SVG> element in an html document.
> 
> Steps to reproduce:
> In the console, type
> 
> 'innerHTML' in SVGSVGElement.prototype 
> 
> Results:
> On Firefox and Chrome: true

Is that the case for any SVG element in an HTML document? Even for <rect>, <circle>? Or just outer <svg> element?

> On webkit: false
Comment 2 Ophir LOJKINE 2014-08-07 06:15:28 PDT
This is the case for all SVG elements (they all inherit from SVGElement, which doesn't have innerHTML)

> 'innerHTML' in SVGRectElement.prototype
< false

> 'innerHTML' in SVGElement.prototype
< false
Comment 3 Dirk Schulze 2014-08-07 06:27:02 PDT
(In reply to comment #2)
> This is the case for all SVG elements (they all inherit from SVGElement, which doesn't have innerHTML)

I was asking for Blink and Firefox. Does it work for all elements there, or just on the root <svg> element in HTML? (Beside all HTMLElements of course.)

> 
> > 'innerHTML' in SVGRectElement.prototype
> < false
> 
> > 'innerHTML' in SVGElement.prototype
> < false
Comment 4 Ophir LOJKINE 2014-08-07 06:30:55 PDT
> I was asking for Blink and Firefox. Does it work for all elements there, or just on the root <svg> element in HTML? (Beside all HTMLElements of course.)

Yes, it works on every svg element on chrome and firefox (because all SVG elements inherit from SVGElement).
Comment 5 Dirk Schulze 2014-08-07 06:33:30 PDT
(In reply to comment #4)
> > I was asking for Blink and Firefox. Does it work for all elements there, or just on the root <svg> element in HTML? (Beside all HTMLElements of course.)
> 
> Yes, it works on every svg element on chrome and firefox

Ok. So they probably moved innerHTML on Element or added it to SVGElement. I assume innerHTML = "<rect>" still gives you an HTMLUnknownElement/HTMLElement on Blink and Firefox?


> (because all SVG elements inherit from SVGElement).

Hehe, SVG elements always inherit from SVGElement and always did. The problem is/was that innerHTML is just defined for HTMLElement.
Comment 6 Ophir LOJKINE 2014-08-07 06:45:00 PDT
> Ok. So they probably moved innerHTML on Element or added it to SVGElement. I assume innerHTML = "<rect>" still gives you an HTMLUnknownElement/HTMLElement on Blink and Firefox?

Yes. In the Firefox console:

> div = document.createElement("div");
> div.innerHTML = "<svg></svg>";
> div.firstChild.innerHTML = "<rect>"
> div.firstChild.firstChild.__proto__
< HTMLUnknownElementPrototype

(But IMO, it's a pitty. It makes it more complex to use templates to create SVG elements, for example).
Comment 7 Ophir LOJKINE 2014-08-07 06:48:15 PDT
And firefox folks intend to change that behavior:
https://bugzilla.mozilla.org/show_bug.cgi?id=886390
Comment 8 Ophir LOJKINE 2014-08-07 06:50:19 PDT
And in chrome, it works:
< div = document.createElement("div");
< div.innerHTML = "<svg></svg>";
< div.firstChild.innerHTML = "<rect>"
< div.firstChild.firstChild.__proto__
> SVGRectElement
Comment 9 Caitlin Potter (:caitp) 2014-09-08 14:42:46 PDT
The base interface for SVGElements does not have innerHTML exposed to scripts in its IDL --- in Blink and Gecko, innerHTML is exposed on the Element interface rather than HTMLElement interface, so they can share this common functionality.

It's probably not a terribly difficult patch to write to fix this, if I have some spare cycles in 2 weeks I'll be happy to take a shot at it.
Comment 10 Caitlin Potter (:caitp) 2014-09-08 14:53:28 PDT
(In reply to comment #9)
> The base interface for SVGElements does not have innerHTML exposed to scripts in its IDL --- in Blink and Gecko, innerHTML is exposed on the Element interface rather than HTMLElement interface, so they can share this common functionality.
> 
> It's probably not a terribly difficult patch to write to fix this, if I have some spare cycles in 2 weeks I'll be happy to take a shot at it.

fwiw, the webkit treatment appears to be spec-correct, but I would treat it as a bug due to being incompatible with 2 major vendors.
Comment 11 Julien Sanchez 2014-09-10 02:51:03 PDT
(In reply to comment #10)
> fwiw, the webkit treatment appears to be spec-correct, but I would treat it as a bug due to being incompatible with 2 major vendors.

It's no more correct. The spec has been fixed last year [1]. innerHTML is now defined on Element (implemented in Chrome [2] and Firefox) *and* should create elements with correct namespace (ok in chrome [2], not yet in Firefox [3]).

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924
[2] https://code.google.com/p/chromium/issues/detail?id=311080
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=886390
Comment 12 Julien Sanchez 2014-09-10 06:34:33 PDT
Testcase (http://marianoguerra.github.io/bugs/svgbug/) from the following issue on Github: https://github.com/facebook/react/issues/1900 .
Webkit is also impacted as innerHTML is not defined on SVG elements.

Only the second example ("innerHTML") is relevant here. 
It is certainly more complicated than just define innerHTML on Element because it should also create the <text> node as SVGTextElement and not as HTMLUnknownElementPrototype.
Comment 13 Caitlin Potter (:caitp) 2014-09-10 06:40:35 PDT
(In reply to comment #11)
> (In reply to comment #10)
> > fwiw, the webkit treatment appears to be spec-correct, but I would treat it as a bug due to being incompatible with 2 major vendors.
> 
> It's no more correct. The spec has been fixed last year [1]. innerHTML is now defined on Element (implemented in Chrome [2] and Firefox) *and* should create elements with correct namespace (ok in chrome [2], not yet in Firefox [3]).
> 
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924
> [2] https://code.google.com/p/chromium/issues/detail?id=311080
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=886390

Not according to any of the DOM specs which have made it to REC, or the WHATWG's DOM.

However, this is academic, because if 2 major vendors are exposing this on Element, then it really doesn't matter what the spec says.

(In reply to comment #12)
> Testcase (http://marianoguerra.github.io/bugs/svgbug/) from the following issue on Github: https://github.com/facebook/react/issues/1900 .
> Webkit is also impacted as innerHTML is not defined on SVG elements.
> 
> Only the second example ("innerHTML") is relevant here. 
> It is certainly more complicated than just define innerHTML on Element because it should also create the <text> node as SVGTextElement and not as HTMLUnknownElementPrototype.

Yes, it's obviously necessary to use the correct parsing insertion mode. By "not terribly difficult" I'm not saying it's a one-line patch, just that it's clear what is needed to be done.

Would you care to write the patch? I will not have time for at least 2 weeks.
Comment 14 Julien Sanchez 2014-09-10 08:14:35 PDT
> Not according to any of the DOM specs which have made it to REC, or the WHATWG's DOM.
> 
> However, this is academic, because if 2 major vendors are exposing this on Element, then it really doesn't matter what the spec says.

Right. I was referring to the DOM parsing living standard and latest candidate rec.

> Yes, it's obviously necessary to use the correct parsing insertion mode. By "not terribly difficult" I'm not saying it's a one-line patch, just that it's clear what is needed to be done.
>
> Would you care to write the patch? I will not have time for at least 2 weeks.

I would be really happy to do it. Unfortunately, I am afraid that it would be too difficult for me and presently I have neither enough time nor deep technical knowledge of Webkit to make it right and quick (within your two weeks for instance). However, I will try have a look at least out of curiosity.
Comment 15 Caitlin Potter (:caitp) 2014-09-10 08:22:58 PDT
(In reply to comment #14)
> > Not according to any of the DOM specs which have made it to REC, or the WHATWG's DOM.
> > 
> > However, this is academic, because if 2 major vendors are exposing this on Element, then it really doesn't matter what the spec says.
> 
> Right. I was referring to the DOM parsing living standard and latest candidate rec.
> 
> > Yes, it's obviously necessary to use the correct parsing insertion mode. By "not terribly difficult" I'm not saying it's a one-line patch, just that it's clear what is needed to be done.
> >
> > Would you care to write the patch? I will not have time for at least 2 weeks.
> 
> I would be really happy to do it. Unfortunately, I am afraid that it would be too difficult for me and presently I have neither enough time nor deep technical knowledge of Webkit to make it right and quick (within your two weeks for instance). However, I will try have a look at least out of curiosity.

Cool, the Blink implementation should serve as somewhat of a guide --- it looks like much of editing/markup's API has not changed too much since the Blink fork, and the Blink innerHTML routine is just a call to createMarkup() with "this" (*this in the case of WebKit) and the element's childNodes --- It probably needs some adjustment to work correctly in WebKit, but following those lines is probably adequate, provided WebKit's createMarkup() is smart enough to figure out the correct insertion mode to use.
Comment 16 Julien Sanchez 2014-09-10 13:28:56 PDT
(In reply to comment #15)
> Cool, the Blink implementation should serve as somewhat of a guide --- it looks like much of editing/markup's API has not changed too much since the Blink fork, and the Blink innerHTML routine is just a call to createMarkup() with "this" (*this in the case of WebKit) and the element's childNodes --- It probably needs some adjustment to work correctly in WebKit, but following those lines is probably adequate, provided WebKit's createMarkup() is smart enough to figure out the correct insertion mode to use.

Thanks a lot for the guidelines. I didn't even think to look at related Blink changes. Now that I did, it doesn't seem so hard to try and adapt them.
Comment 17 Damien Nozay [:dnozay] 2014-11-14 12:04:19 PST
see also https://bugs.webkit.org/show_bug.cgi?id=136903 (bug 136903)
there is some work in progress there.
Comment 18 Sylvain Galineau 2014-12-15 10:01:25 PST

*** This bug has been marked as a duplicate of bug 136903 ***