Wrong x/y positioning in Firefox

[48DESIGN]

Hi everybody,

 

I'm trying to animate an SVG (that I didn't create) for client project. It works well in Chrome and even Internet Explorer (9-11), however, I'm running into trouble with Firefox. The y positioning of the elements is completely incorrect, some parts move up instead of down and parts that should visually "stick" together end up shifted.

 

 

Interestingly, I found out that if I use "yPercent:" instead of "y:" and adjust the values accordingly, the animation works as intended throughout all browsers. Take a look at this modified codepen:

 

See the Pen xGQEXr by anon (@anon) on CodePen

 

I don't feel comfortable using yPercent. On the one hand, it's not "semantically" correct in my view, because I actually don't need and don't want to rely on the elements' heights for just moving them around. And on the other hand, if I want to move two elements around that visually represent the back and front side of one single object, I have to find the correct percentage values for each of them, which doubles my work. (I should add that I will have to animate several similiar SVGs for the project.)

 

I'm aware of the fact that the SVG could be cleaner (e.g. not using <use>, the various transforms and the viewBox attributes on the symbols...), but I want to avoid having to clean up and effectively rebuild every single SVG file. And apart from that, I would really like to know what causes these browser inconsistencies that GSAP isn't able to compensate and would be glad if anyone could come up with a way to fix it.

 

Thanks in advance for any help

Constantin

See the Pen zGMKPN by anon (@anon) on CodePen

[PointC]

Hi 48DESIGN   ,

 

I just took a look at your CodePen in Chrome, FF and IE and I'm seeing the exact same animation in each browser. No strange y positioning is showing up in Firefox. Maybe you've changed something since your original post, but at this time, I don't see any browser differences.

[Carl]

I am seeing the issue in FF 39 on Mac using the original pen here: http://codepen.io/anon/pen/zGMKPN

 

It seems that most items are not moving down far enough.

And yes, you should not have to use yPercent (although it is helpful to know that it works).

 

We will have to look into this further. Will report back when we have something conclusive.

[Jonathan]

I see the same issue on FF 39 Windows 7 64-bit

[PointC]

Correction - after Carl's post, I tried the Codepen again on a different PC with the latest version of FF(39)  and it is indeed showing some y positioning problems. The other PC I tried has an older version of FF (30) and works perfectly fine. 

[48DESIGN]

Thank you all for the quick replies! Maybe the fact that it works in an older FF version is helpful for getting closer to a solution!

Let me know if there's anything else I can provide or try out!

[GreenSock]

From what I can tell, the issue has to do with a bug in the way Firefox reports getBBox() on <use> elements. It includes the "x" and "y" attributes in the computed value whereas other browsers don't. One solution would be to adjust your SVG so that you just merge those values into the "transform". In other words, currently you're using two different values to affect position - x/y attributes AND a transform matrix, but you could just use the transform matrix instead so that the x/y don't taint the getBBox(). I'll try finding another solution but I wanted to at least get back to you about what I believe the problem is and how you could avoid it in the short term. 

[48DESIGN]

Thanks so much for taking the time for an evaluation! I will try merging the x/y and transform - if that works, maybe I can automate it with a script.

I will also file a bug report with Mozilla, but I will await your final response on this matter first.

 

Cheers!

[48DESIGN]

Just a quick update to let you know that unifying the x and y attributes with the matix didn't work out. I suspect that the viewBox attributes on the <symbol>s may have something to do with this as well..

[GreenSock]

Here's a solution - just add this to your JS:

//test for SVG bug that causes SVG <use> elements to include "x" and "y" attribute values in the results of getBBox(). Firefox 39, for example. If the bug is found, overwrite the getBBox() method with a new one that corrects the behavior. 
(function testSVGBug() {
  var useNodes = document.querySelectorAll("use"),
      i = useNodes.length,
      node = useNodes[0], 
      x = parseFloat(node.getAttribute("x")) || 0,
      bbox = node.getBBox(), 
      hasBug;
  node.setAttribute("x", x + 20);
  hasBug = (node.getBBox().x !== bbox.x);
  node.setAttribute("x", x);
  if (hasBug) {
    while (--i > -1) {
      node = useNodes[i];
      node.originalGetBBox = node.getBBox;
      node.getBBox = function() {
        var bbox = this.originalGetBBox();
        bbox.x -= parseFloat(this.getAttribute("x")) || 0;
        bbox.y -= parseFloat(this.getAttribute("y")) || 0;
        return bbox;
      };
    }
  }
})();

Better? 

[Jonathan]

That is pretty awesome Jack!

[48DESIGN]

That's awesome. You, Sir, are awesome. And GSAP is awesome. Did I forget anything?

Thanks a lot, the fix will save us quite som time and nerves...

 

Here's an updated codepen that includes the fix:

See the Pen LVXBxY by anon (@anon) on CodePen

 

Cheers!

 

P.S: If anyone's interested, here's the bug report at Mozilla's Bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=1189042

Edited July 29, 2015 by 48DESIGN

[48DESIGN]

Here's an update: Mozilla devs feel they are following the specs, so the other browsers are behaving wrong. I'm not taking on the hassle of either getting the spec changed or filing bug reports with several other vendors, but rather live with yet another browser inconsistency.

 

Thanks to your fix, that won't be a problem, and you might consider including it in a future update.

[GreenSock]

I guess I can see what they're saying, but of course we just want consistency among browsers. Another problem I noticed in Firefox is that it throws an exception when you try to call getBBox() on an element in a <symbol>. Here's a simple codepen that shows some of the behavior in various browsers (you'll need to crack open the console and see the differences in what gets reported)

http://codepen.io/GreenSock/pen/f2f2a09d89825763794e105fe045a5fa/