SVG Element not extended in Firefox 11 #2331

blaher opened this Issue Mar 14, 2012 · 27 comments


None yet

8 participants


This only happens on the new Firefox 11, it works fine on previous versions, but shoots out an error "Error: $("svg2").setStyle is not a function Source File: Line: 13". I'm working on it for an unreleased version of my map, and noticed it stopped working after my Firefox updated.


I should probably mention, if I comment that line out (which is really no longer needed), I then get "Error: element[name] is undefined
Source File:
Line: 3072".

I have also updated to 1.4.5 on the newer version, but get the same error, except the second error reads "Error: f[a] is undefined
Source File: ...
Line: 234".

MooTools member

For some reason the <svg> tag isn't a instance of Element anymore...

For example try

$('svg2') instanceof Element

in firefox or chrome, firefox returns false and chrome returns true.
Though you'd think the <svg> element in a HTML document would be an Element, which would have Element.prototype so all the MooTools methods.

MooTools member


document.createElement("svg") instanceof HTMLElement

returns true in Firefox 12.

MooTools member

but it does look like mootools does something somewhere:

With MooTools:
No framework:


I met the same problem on my maps. Should I wait or shoud I go ?!


And on my maps, too. It breaks the whole thing hopelessly because of the events.


However, it works with 1.2.5


Has anyone been able to make a work around for this, for the time being? With Arian's findings, I thought about inserting a new SVG element, and injecting all the contents and attributes of the other SVG element in to the new one, and then delete the old one (just for FF11). However, without any MooTool's functions being attached to the old element, my memory has been proving difficult to do it the old school JS way. Plus,I'm not sure if this will entirely work, but theoretically it should.


It won't. It won't even render, in my opinion. I used downgrading to 1.2.5 as a workaround. Since I have a project of many thousands of lines of code, which I had already painfully upgraded to 1.3 several moths ago, I couldn't do it gracefully, so I just built my own version of compatibility layer and included it into .more.

Now I'm waiting until either FF or Mootools would fix this bug. I put my hope rather in Mootools team.


I'm facing the same issue too. Any idea how to hack it ?


Anyone from the core team care to share a patch before it hits the official release?

This is really messing with my zen...

MooTools member

Ok, so the problem is this, MooTools does something like:

Browser.Element = window.Element;
var Element = function(tag, properties){
    // do stuff
Element.prototype = Browser.Element.prototype;

That way the prototypes are shared.
For some unknown reason however, the new methods in Browser.Element.prototype don't show up in the prototype chain of SVGSVGElement.

In plain js:

var OldElement = window.Element;
var svg = document.getElementsByTagName('svg')[0];

// svg is an instance of OldElement
console.assert(svg instanceof OldElement);

// implement new property in OldElement
OldElement.prototype.test = 'test';

// Now because svg is an instance of OldElement, it should have this property
// but it has not
console.assert(svg.test == 'test', 'svg.test should come from SVGSVGElement.prototype');
// while a normal element has
console.assert(document.body.test == 'test', 'document.body.test should come from HTMLElement.prototype');

here the svg.test == 'test' assertion fails in firefox.

So as far as I could see this is a Firefox bug.
/cc @sebmarkbage, @jdalton, @kamicane.

MooTools member

Actually this already fails (in plain js):

Element.prototype.test = 'test';
var svg = document.getElementsByTagName('svg')[0];
console.assert(svg.test == 'test');
MooTools member

@arian, is there a way to fix it temporarily in 1.3-1.4 through Element.Constructors, extending svg elements in constructor? I've managed to do that on 1.2.5, but I'm facing the perspective of downgrading the whole project to it for a yet unknown timespan, which would be mess, really. Whether or not Firefox will be releasing the fix in the next version, a temporary solution is needed. Any suggestions highly appreciated

My approach in 1.2.5:

MooTools member

@w8r, you can probably do the same for 1.3, 1.4.


The problem is, I'm not getting anything in Element.Prototype in FF11, and cannot use Element.prototype for it


I'm speaking about 1.3-1.4 now


I think I've found the solution for 1.3 and 1.4. You can look at the test here

(function(svgtags) {
    var ns = '',
        methods = (function(proto, cls) {
            var hash = {};
            for (var f in proto) {
                if (cls.hasOwnProperty(f)) {
                    hash[f] = proto[f];
            return hash;
        })(Element.prototype, Element);

    svgtags.each(function(tag) {
        Element.Constructors[tag] = function(props) {
            return (Object.append(document.createElementNS(ns, tag), methods).set(props));
})(['svg', 'path', 'circle']);

w8r, thanks for the workaround! it works fine!

MooTools member

The Firefox bug was resolved/fixed some days ago:
So hopefully that fix will land in Firefox soon.


If the fix will land only in the next major release, it's no relief, for FF11 will stay around for a while. I propose a detection like this for a while

var svgNeedsPatching = !(document.createElementNS(ns, 'svg') instanceof Element);
Element.Constructors[tag] =
                            svgNeedsPatching ? function(props) {
                                return Object.append(
                                        document.createElementNS(..., tag),
                            } : function(props) {
                                return document.createElementNS(..., tag)
MooTools member

Firefox 12 was just released, and it fixes the issue. It's safe to assume every Firefox 11 user will update to 12, since now updates are so easy. That said, I have nothing against this fix being included (atleast for some time).

MooTools member

Whops, I assumed wrong. Seems this is not fixed in 12 yet.

MooTools member

This bug should land in Firefox 13 (It should be in Aurora soon according bugzilla). So in 6 weeks most users will update to Firefox 13, in the mean time I propose people can use this fix by @w8r, it doesn't have to be within mootools itself. I don't think we need to release a separate version with this temporary fix.


My thoughts exactly, in addition it's better to customize the patch with the SVG tags for individual projects.
@arian, @kamicane, if you have any guidelines the fix should follow, please tell me, I'll arrange it accordingly.

MooTools member

This seems to be fixed in firefox 13.

@arian arian closed this May 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment