Transform merge bug

[zachschnackel]

Hi all!

 

I'm noticing an issue with GSAP merging in transform properties originally formed in the CSS. I've attached a CodePen to show the issue. In Chrome, you'll see that both Dropdowns align to the center as intended. But in Firefox, IE11, and Edge -- it looks like the transform matrix that is generated is not including the calculated width of the dropdown component when transitioning. We can't use fixed widths (in the example that works) for a certain application, and found it really odd that only Chrome and Safari are handling this alright. Let me know if you need anymore info. Thanks as always!

See the Pen 6ced08c98313798d5ae27219770a4596 by zslabs (@zslabs) on CodePen

[GreenSock]

Very interesting indeed. Here's what I discovered...

1. It is indeed a browser bug, unrelated to GSAP. In fact, different bugs for Chrome/Safari than Firefox/IE/Edge
2. You can see it by adding this to the top of your codepen (even without any GSAP code):

   var bug = document.querySelector(".dropdown-content--bug");
   var cs = window.getComputedStyle(bug);
   console.log(cs.transform); //in Chrome/Safari, it's "none" (wrong), and in Firefox/IE/Edge, it's "matrix(0.5, 0, 0, 0.5, 0, -7.5)" (also wrong - notice the x-translation is gone)

3. It has to do with the fact that you've got display:none on that element. Browsers tend to choke on that because the element isn't being rendered at all, thus its geometry isn't in the pipeline to report accurately (well, that's my assumption). So when GSAP asks "okay, what's the current transform", it's getting bad data from the browser.
4. If instead of toggling display:none/block, you did visibility:hidden/visible, it resolves things in Webkit browsers...but not the others.
5. In Firefox/IE/Edge, they'll actually report the transforms even with display:none EXCEPT percentage-based values! So your translate(-50%, 7.5px) becomes translate(0, 7.5px). Well, it's reported as a matrix() but it's basically the same thing. 

We implemented a workaround a while back in GSAP for the display:none glitch that assumed it'd report "none" or a standard matrix in this condition but now Firefox/IE/Edge are doing this hybrid "kinda right, but not with percentages" thing, it failed that test internally (for performance reasons, we were skipping all that detection if the reported matrix wasn't "none" or an identity matrix). Looks like we'll have to remove that assumption now and run the logic regardless. In that condition, it has to toggle the display to block, get the computed style, and flip back again (all internally). Bummer. I've implemented that change in the upcoming release which you can preview (uncompressed) at:

https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

 

Better? 

 

So basically, the moral of the story is that this issue is related to multiple browser bugs and inconsistencies, but GSAP has your back and you won't need to worry about it in the future

[zachschnackel]

Really appreciate the thorough explanation around this! I dug into this and also found that if I perform a `set()` with the display property first, THEN do the rest of the tween after that everything also works correctly. I'm certainly always a stickler for performance, so if you've found any regressions in your update, maybe something to note in the docs about that browser quirk and the workaround I mentioned (just food for thought). Thank you for always having our back and for continuing work on such an awesome platform. Hope you have a great weekend!