Jump to content


Power Easing adds Black Background for Transparent PNG'S

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts



first of all i love the Engine.  I use the latest 1.11.1 engine.


Today, after the FireFox 25 Update has been released,  we get 2 very strange effects in Firefox on MAC.


1. Some Easing (like power3.ease..., power4, power2..) adds a black background for Transparent PNG Images. If i change this easing to linear or i.e. Back.easeOut the black bg disappear.  Live:  http://www.themepunch.com/codecanyon/revolution_wp/fullwidth.php (slide 2)  See Video also: http://screencast.com/t/JiQap5oBlW

2. In Firefox the Animated Iframes with Vimeo Videos in it are not Clickable. Only in Firefox, only on PC. If i remove greensock animations of the iframe, videos are clickeable.  See live: http://www.themepunch.com/codecanyon/revolution_wp/fullwidth.php (at slide 4 and slide 5)


Any tipps or advise would be great !


Thanks a lot,


Krisztian from ThemePunch

Link to comment
Share on other sites

Hello, and Welcome to the GreenSock Forums!


just to clarify..


you're only seeing this issue in latest Firefox 25 on MAC ?


regarding issue #1:


is the image being used uploaded via the wordpress media uploader or is the image/png just on the page as a static image and not being pulled from wordpress? (the reason i ask is that wordpress sometimes has an issue with png24 images when uploaded via the wordpress media uploader and sometimes causes png images to have that black background issue)


does the issue still happen if you are animating the png/image parent.. like say its parent div?


regarding issue #2:


if you add pointer-events:none; on .slotholder does it allow the click through?

.slotholder {

what styles and/or transforms are you seeing on the iframe when its not clickable??


note: Slider Revolution is an awesome slider :)

Link to comment
Share on other sites

First of all, I agree with jonathan - Slider Revolution looks awesome. Good job. 


Second, I honestly cannot imagine how the ease could possibly affect the PNG alpha areas like that. Absolutely baffling - we don't do anything special to images. All the engine does is set the individual properties that you specifically request, and the ease only alters the rate of change - that's it. 


I briefly tried reproducing the problem outside your page and had no luck - could you whip together a very simple codepen or jsfiddle that demonstrates the issue? It's very difficult to troubleshoot the live page because it has tons of other things happening that are unrelated to GSAP, so it's almost impossible to isolate effectively without spending many hours. We'd definitely like to solve any issues that exist in GSAP - we just need to verify that it's actually an issue with GSAP first, so an isolated example would be super helpful.

Link to comment
Share on other sites



thanks for your feedback.


1.I made for you a test here http://jsfiddle.net/kzkV9/2/  Please see in FireFox 25 on a MAC :( The Problem exist also without any other plugins, css etc included. No Wp nothing special.  Please load the page and run the fiddle a few times :(


2. Thanks, that is a great solution ! 




Krisztian from ThemePunch

Link to comment
Share on other sites

thanks for the example Krisztian..

  • does it still show black even if you add the below to your img:
.anim1 > img,
.anim2 > img { 


.anim1 > img,
.anim2 > img {

also when saving the png images .. 

  • are you saving them in Photoshop or Fireworks, or other image editor?

i am showing that the image imac1.png is a png-32.

  • Does this still happen if you use a png-24 or png-8?

I know that when an image is saved as a png-24 with transparency in Photoshop, that Photoshop will actually save the image as a PNG-32. I have sometimes seen depending on how the PNG or GIF was saved or copied, it would cause that type of black background where the transparency should be in Firefox on Mac.


Copying image with transparency gives black background. Mozilla has a bug report regarding PNG alpha issues:





it doesnt look like a GSAP issue but a possible PNG display issue either in Firefox 25 for Mac or some other Firefox Bug:

  • have you seen this issue with Firefox 24 Mac?

Im not seeing this issue on Mac OS X 10.6.. 

  • what version of MAC are you seeing this on?


  • Like 1
Link to comment
Share on other sites



thanks for your reply.  The Background transparent does not help unfortunately. 


The Two Animation i am showing in this Demo is using the same image. The only difference between the two animation is only the EASING. 


So we can be sure, it is not based on the PNG image, and not based on any CSS Settings. It has something to do with the Perspective and/or easing.  


If i remove the Perspective, both easing works in Firefox.  But unfortunately i need that perspective, so the question, why Power3 easing looks like that, and Linear or Back easing does not look like that ?   


Please see Exactly my Examples.  Both Div is 1:1 same. Animation is 1:1 same, only the Easing is different !   One has no Black Background, the other has it.


I have Maverick now,  OS X Build 13a603.  FireFox 24 on same MAC OS was fine.  As i wrote above it happens since FireFox 25 is out. 


Thanks again, and i hope you can give me some solution soon. 





Link to comment
Share on other sites

Thanks for creating the example - very helpful. 


This definitely looks like an odd Firefox bug. After a bunch of testing, here's what I discovered...


I could only get it (the problem) to happen inside an iframe in Firefox 25, and only when some sort of 3D effect was applied (even a perspective), and only when you start at a scale that's 0.0005 or less. Weird, I know. So if you try your tween and start at scale:0.001, it's fine. It's also fine if you're not looking at it inside an iframe (at least in all my tests). 


The reason it seemed like the ease was the problem was because if the value didn't change beyond a certain threshold inbetween frames, Firefox choked and just rendered the funky black in the alpha areas. For example, in a linear ease, let's say the value changed 0.001 on every frame. Fine. But if you use Power3.easeInOut, the amount of change at the beginning (and end) is VERY small, so inbetween the 2nd and 3rd render (for example) it may change 0.0000000000001 whereas a linear ease would change 0.001. Firefox didn't like the tiny change when the scale was so tiny. 


My guess is that Firefox has some internal logic in its rendering queue that says "if an element is smaller than ____, we'll just treat it as invisible and don't calculate the PNG's transparent pixels" and then when the scale increased there was a flaw somewhere in their logic that caused the semi-transparent portions of 32-bit PNGs inside iframes to get blacked out instead of getting triggered to render correctly. Totally a guess.


I've attached a revised version of GSAP (preview of 1.11.2) that implements a workaround in Firefox that essentially looks for that condition and if the scale is sufficiently small, it'll make it 0.00002 instead which is visually the same anyway, but it seems to work around the Firefox bug. 


Make sense now? 


Side note: this is yet another reason to use GSAP - silly little browser bugs like this get worked around for you in the core so that you don't have to worry. Guys like you help identify browser issues (thank you) and we do our best to implement a workaround so that everything "just works". Most people will never even know that Firefox has that funky issue. There are a bunch of other examples of that type of thing that we've made invisible to users (like 3D transformOrigin bugs in Safari, iOS requestAnimationFrame hiccups, tons of oddities in IE, etc.) 


Please let us know if this version resolves things for you. 


  • Like 4
Link to comment
Share on other sites



thanks for your great support Jack.   As you know i am also Plugin author, and right now i get massive feedbacks about CPU Consuming transitions in FF, black Backgrounds, and not clickable elements after 3d animating them. 


The fix you provided helps olny partly. if i use Power3 easing and perspective 600 as in the jiddle example, it seems to work,  but that there are many other combinations where it breaks again.


I reported a few bugs at Firefox also about CPU Consumes in the last days, but no feedback at all so far.


Can you advise me how should i go further ? Should i create further jsfiddle examples for you, or do you belive that Mozilla will fix his issues soon ?  Did you report any bug at Mozilla already ?


Thanks a lot for your great support so far, and if you wish we can discuss this also private. You have my email, so just drop me an email and we can maybe short up things ? (just an idea).





Link to comment
Share on other sites

Thanks for the offer to take the conversation offline, but I actually prefer to keep it in this thread as much as possible so that other folks can benefit. The forums can be an amazing tool for learning and searching for solutions. 


Anyway, yes, I'd love to see other examples of things breaking in Firefox - can you show me how to get the funky black background again even after using the new 1.11.2 update? And how to get non-clickable elements after affecting their 3D transforms? (and any other glitches of course). I'm pretty sure none of this is directly related to GSAP, but I do want to implement workarounds wherever possible.


As far as Mozilla fixing the bugs in Firefox, unfortunately I have absolutely no idea and no control over that. I sure hope they fix it promptly, but I have no particular reason to believe it'll happen soon. I'm glad you reported the bug(s). 


Please do shoot me those examples as soon as you can - I'd like to implement any other workarounds in the 1.11.2 release.

Link to comment
Share on other sites

Regarding issue 2 .. transformed elements stop being clickable...


maybe its a Z axis browser bug ?


Looks like Google Chrome webkit has this same bug as Firefox Mac version.. as far as an element losing its click-ability when an element is transformed in the Z axis.. ive noticed this same behavior in Chrome webkit over the past couple of years.


i set up 2 test examples to show you what happens in Chrome when an elements child has been translated in the Z axis

  • Go to Chrome browser and click on both red and green squares. ( you will notice that only the green box throws an alert, clicker_2 )

See the Pen uGImA by jonathan (@jonathan) on CodePen

  • Now go to this example in Chrome browser. ( you will notice that both red and green boxes are click-able now and throw the alert )

See the Pen JLrzD by jonathan (@jonathan) on CodePen


Basically you have to compensate for the negative Z axis, so the child div was translated on the Z axis -50px... so i had to translate its parent div 50px on the Z axis to make it click-able again


I have seen this behavior in various jQuery plugins that try to translate in the Z axis in Chrome


Just thought i might point that Google Chrome (webkit) has tons of bugs that relate to translateZ or also if translate3D - 3rd parameter Z


i wonder if this behavior exists if using scale Z or rotate Z ??


the translate Z behavior of not allowing clicks also happens on Android stock browser and mobile Chrome..



  • Like 2
Link to comment
Share on other sites

Thanks a lot for your feedback.


The solution to move elements on z axis closer or farer would work, however it has an other dark side.  


I compensate this also with the negative Z axis In Webkit. This solution makes elements looking bigger/smaller which could be a problem in some situation.  

I could not found a clean solution for this and for the Android issue yet. Since in my situation the dynamic calculated animations always ends up in a "2d World" the solution to remove any transformations seems to work.  


My next step would be to let elements also be transformed during the slide, and than i will face this problem again.  So i just can hope that the Browser Developers finally go back and follow one direction instead of creating different bugs and acting differently on the same browser requests.


I will play around with the fixes from Jack now and see what else comes up.  One thing i rcognised so far, FF25 and MAC makes bulk transitions extrem slow. I had this problem only in FF25 and only on MAC, so it must be an other fancy bug from Mozilla.  


As soon i have same test i will share with you, seems that you guys gives amazing good support here  :)

Link to comment
Share on other sites

if you need to target only for Firefox MAC using JS object detection:

// check if Firefox
var isFF = !(window.mozInnerScreenX == null);
// get navigator platform "MacPPC" or "MacIntel" 
var platform = navigator.platform;

        if(platform === "MacPPC" || platform === "MacIntel"){
               // is Firefox MAC version





  • Like 1
Link to comment
Share on other sites

Yes, thanks for the snipet ! i was hope to be able to ignore this since the new FireFox 25.0.1 is just out.  But it is even more buggy than 25.0.0. 


1, Animated elements shaking. In slower animations with Easing out they just shake vertical a bit and the borders are not sharp any more. Looks like Interlaced video :)  http://www.themepunch.com/codecanyon/revolution_wp/fullwidth.php  or as short video here: http://screencast.com/t/Fp4RIEtFm


2, Even more CPU Issues and very strange border rendering you can see here:

http://www.themepunch.com/test2/  (made a quick test only here first).  The Screenshot for this on MAC FF : http://screencast.com/t/SbxIWExLL  (tested it on 3 different Macs, to make sure it is not a failure of the GPU)


I am pretty sure it is not Greensock based, but i thought i share this with you, in case some other customer contacts you.  In case you have any idea for a workarond, i would be glad .)


Cheers !

Link to comment
Share on other sites

Yeah, Firefox seems to be the most buggy by far when it comes to implementing transforms. Things would randomly disappear when 3D transforms were applied a few versions ago in Firefox, and we implemented a workaround for that under the hood. It looks like that's resolved now, but it looks like you stumbled across some brand new bugs (thanks Firefox!). I'm not 100% sure yet, but it appears as though the funky border issue had to do with defining a perspective when no 3D properties are being utilized, so the attached version senses that condition and zeros out the perspective only in that case (that obviously shouldn't be necessary).


Please let us know if this resolves things for you. And just to be clear, I'm pretty confident that none of the issues were related to GSAP at all, but we're doing our best to figure out ways to work around bugs in Firefox itself. 


  • Like 3
Link to comment
Share on other sites

Regarding not so sharp, jaggy or strange border rendering on Firefox Mac...


Have you tried this one Firefox hack to help smooth edges on elements with transforms:


Smooth Edges on Elements with Transforms:


EXAMPLE - Open in Firefox: 

See the Pen smvwb by jonathan (@jonathan) on CodePen


It used to fix the striped border bug in Opera, but i have seen it help smooth border edges in Firefox ..


please try this:


adding a border or/and outline property to transparent on the transformed element:

#elementWithTransform {
         border: 1px solid transparent;

also you can try also setting the outline property to transparent as well.. i have seen this hack work on Firefox Mobile version:

#elementWithTransform {
         outline: 1px solid transparent;


and to be safe you can set both CSS properties.. border and outline:

#elementWithTransform {
         border: 1px solid transparent;
         outline: 1px solid transparent;

see if that helps? :)


the browser will probably convert transparent to rgba(0,0,0,0) but thats ok :P




also here are a couple bug reports from Mozilla:


Bug 594380 - Boxes become jagged when using CSS transition to rotate them



Bug 593792 - moz-transition rendering with Glitches/Artifacts on accelerated Layers


Link to comment
Share on other sites

Thanks for the prompt reply ! Great to get this amazing support from you ! 



Thanks for the transparent border, the strange background rendering and the unsharp edges at animation have been eliminated now.


FireFox Bug Still Exist: 

http://themepunch.com/test2/ If you play around the "filter buttons" in FireFox 25.0.1 (on MAC), you will see how slow the animated elements are.  I tried x,y transitions and also left/top position changes. Same issue.


In Chrome, Safari, and even on FireFox on a PC this works perfect.


Checking the Hardware i see a CPU usage over 50% during the transitions (sometimes it reaches the 90% also). Compared to chrome it stays under 4%.


If i reduce the amount of animated elements (change row and columns in test) or i use a higher delay between animations, things getting smoother, but still not acceptable.


I am open for any good ideas, tricks etc :)  Also Mozilla started to work on my Reported issue, so hopefully we have some good news from there as well.


Thanks again,



Link to comment
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.