Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
mrkos67

SVG transformOrigin inconsistent in Firefox?

Recommended Posts

Here's a weird one. 

 

http://dev.option5.net/CHRN/16/004/

 

Open this link in Firefox, and navigate linearly (clicking the arrows on the right) through this demo. the first screen after the intro is the "full flow" and the pumps spin as they should, specifically the PBP Pump (lower right). Click the right arrow a few times till you see the "Using PBP with SCUF" screen — the PBP pump doesn't spin around the set transformOrigin (it takes a bigger radius around which it's spinning). 

 

Now, refresh that link, and using the hamburger menu icon in the top right, jump directly to the "Using PBP with SCUF" screen. The PBP Pump *should* be spinning at the correct transformOrigin — at least it does for me when I've tested. 

 

This happens on several of the other screens as well — the PBP pump on most of the "PBP ..." screens and on one of the screens, another pump does it as well (with a bigger radius and a different origin). Again, when refreshing and jumping directly to each of these screens, they seem to spin correctly.

 

The code for the pumps on each screen of my demo are all the exact same: some work in Firefox — the "Full Flow Path" seems to always show the spinning pumps, specifically the PBP pump, correctly whether navigating linearly or jumping to that screen from the menu. Not sure why this works, and others don't.

 

I've attached a codepen of the basic SVG and JS code, but it seems to always work there. 

 
I'm clueless. Is this a bug in Firefox? (Chrome and Safari on Mac function perfectly)

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

Link to post
Share on other sites

A few questions for you: 

  1. You cannot reproduce the problem in codepen as a reduced test case, right? It's only a problem in the context of your entire site where there are a lot of other moving parts? 
  2. Are you using display: flex anywhere (Firefox has a bug related to display:flex and SVG)? 

I'd strongly recommend that you take the reduced test case in codepen and slowly build it up to be closer and closer to your "real" page so that you can see exactly where it breaks. I have always found that to be the best way to zero in on a problem. Time-intensive, yes. Annoying, sure. But extremely effective :) 

  • Like 2
Link to post
Share on other sites

1. I went super basic in Codepen to get something to show; I haven't really played with it much since I'm not sure how much budget I have with the client.

2. Nope, no "display:flex;" anywhere.

 

I'll see what my client says about whether I have the time/budget to track this down. Just figured I'd post here and see if anybody has run into something like this before.

Link to post
Share on other sites

There is some kind of svgOrigin problem on that pump group that is flying out of position. If you use the inspector in Chrome, you'll see the y position of the two pump groups at a position of 461 (& a lengthy decimal). Of course, they both spin correctly. Looking at the inspector in FF, I see the problem pump group has an svgOrigin y position of 285 (and a lengthy decimal) while the correctly spinning one is at 461 like it is in Chrome.

 

Since one pump group spins correctly in FF, I'd look at what you're doing differently on that one. I didn't dig through your JS to find where/how you set those origins, but I think that's your trouble spot.

 

Good luck and happy tweening.

:)

  • Like 1
Link to post
Share on other sites

that's the thing, though: i'm not doing anything different for each pump group. all the screens use the exact same SVG code for the different groups and sections within (minus a few groups for the differences between the different screens). I've added the same class to each of the groups in the SVG code so that I can call the TweenMax call, once, on that class (which targets all of them). there's no x/y on any of the groups in the code, so it's not like some are getting repositioned before the JS code is called on it. Even when I take the transformOrigin off the TweenMax code, the pump groups still behave inconsistently.

 

If each pump group would act consistently on the same screen (PBP, Replacement, Effluent, etc), and each of the same pump groups between SVGs on the different screens (whether jumping directly, or progressing linearly through the demo) would be consistent, this wouldn't be such a head scratcher. 

 

As it stands now, though, it's inconsistent behavior in only one browser which makes me think it's a bug in the browser and not necessarily my code. Hmm.

Link to post
Share on other sites

It could be a FF bug, but since one pump group works in your live site and they both work in CodePen, that still leads me to believe that something is getting changed on that group. I'm not sure what to advise other than what Jack said in Post#2. Take everything out and start adding it back in until it breaks.

 

Happy bug hunting.

:)

  • Like 1
Link to post
Share on other sites

HOLY **** I FOUND IT!

 

It had to do with that group being hidden before the tween was called to animate it when navigating linearly through the demo (the PBP pump wasn't visible on the first screen of each section, but when navigating directly to that screen, I wasn't automatically hiding it). The transformOrigin was getting set to the SVG, not the group (since the group didn't have height/width). I changed my .hidden class to "opacity:0" instead of "display:none" and voila!

  • Like 2
Link to post
Share on other sites

Ah yes, some browsers (Firefox mostly) mis-report bounding box coordinates when the element isn't actually rendered on the screen. Super annoying, I know. Glad you found that. Here's a reduced test case that shows another (slightly different) super weird issue with Firefox and SVG with display:flex and <ul> elements: http://codepen.io/anon/pen/WpROEx?editors=0010

 

Thanks for letting us know you solved it. 

  • Like 2
Link to post
Share on other sites

Yeah - thanks for letting us know. It could help others who land here.

 

We've had a few members with SVG issues and display:none lately. I guess the safe bet is an opacity or autoAlpha of 0. It seems like these browsers are getting fussier and fussier. FF with its box coordinate issues, Chrome and the whole will-change debacle and everyone's favorite - IE. Oh well, if it was easy, everyone would be doing it.

 

Happy tweening.

:)

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×