Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVG Element not extended in Firefox 11 #2331

Closed
blaher opened this issue Mar 14, 2012 · 27 comments
Closed

SVG Element not extended in Firefox 11 #2331

blaher opened this issue Mar 14, 2012 · 27 comments
Labels

Comments

@blaher
Copy link

blaher commented Mar 14, 2012

http://www.allenkeith.com/remodeling-areas-served

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: http://www.allenkeith.com/inc/script/ohio.js Line: 13". I'm working on it for an unreleased version of my map, and noticed it stopped working after my Firefox updated.

@blaher
Copy link
Author

blaher commented Mar 14, 2012

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: http://www.allenkeith.com/inc/script/mootools/new.js
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".

@arian
Copy link
Member

arian commented Mar 19, 2012

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.

@arian
Copy link
Member

arian commented Mar 19, 2012

However

document.createElement("svg") instanceof HTMLElement

returns true in Firefox 12.

@arian
Copy link
Member

arian commented Mar 19, 2012

but it does look like mootools does something somewhere:

With MooTools: http://jsfiddle.net/f36kT/1/
No framework: http://jsfiddle.net/f36kT/2/

@egiguet
Copy link

egiguet commented Mar 20, 2012

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

@w8r
Copy link

w8r commented Mar 20, 2012

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

@w8r
Copy link

w8r commented Mar 20, 2012

However, it works with 1.2.5 http://jsfiddle.net/ctqyR/.

@blaher
Copy link
Author

blaher commented Mar 28, 2012

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.

@w8r
Copy link

w8r commented Mar 28, 2012

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.

@pveiga
Copy link

pveiga commented Mar 29, 2012

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

@oskarkrawczyk
Copy link
Contributor

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

This is really messing with my zen...

@arian
Copy link
Member

arian commented Mar 30, 2012

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];
console.log(svg);

// 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.

@arian
Copy link
Member

arian commented Mar 30, 2012

Actually this already fails (in plain js):

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

@arian
Copy link
Member

arian commented Mar 30, 2012

reported to firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=740811

@w8r
Copy link

w8r commented Apr 17, 2012

@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: http://jsfiddle.net/w8r/zuN6q/

@arian
Copy link
Member

arian commented Apr 17, 2012

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

@w8r
Copy link

w8r commented Apr 17, 2012

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

http://jsfiddle.net/w8r/Kp4wy/

@w8r
Copy link

w8r commented Apr 17, 2012

I'm speaking about 1.3-1.4 now

@w8r
Copy link

w8r commented Apr 17, 2012

I think I've found the solution for 1.3 and 1.4. You can look at the test here http://jsfiddle.net/w8r/u6G5p/

(function(svgtags) {
    var ns = 'http://www.w3.org/2000/svg',
        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']);

@bytehead
Copy link

w8r, thanks for the workaround! it works fine!

@arian
Copy link
Member

arian commented Apr 23, 2012

The Firefox bug was resolved/fixed some days ago: https://bugzilla.mozilla.org/show_bug.cgi?id=740811
So hopefully that fix will land in Firefox soon.

@w8r
Copy link

w8r commented Apr 24, 2012

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),
                                        methods).set(props);
                            } : function(props) {
                                return document.createElementNS(..., tag)
                                        .set(props);
                            };

@kamicane
Copy link
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).

@kamicane
Copy link
Member

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

@arian
Copy link
Member

arian commented Apr 25, 2012

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.

@w8r
Copy link

w8r commented Apr 25, 2012

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.

@arian
Copy link
Member

arian commented May 19, 2012

This seems to be fixed in firefox 13.

@arian arian closed this as completed May 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants