RolandSoos

As a sidenote to this story: All users who had this issue host their site at SiteGround. We contacted with the hosting provider and it turned out that they have an option Site Tools -> External Links Rewrite which rewrites urls in JavaScript files too. Site owners just need to switch it off and everything should work fine. They promised that they will try to fix these false replacements.

Try this: https://codepen.io/mm00/pen/qBWRWKY

@GreenSock, I just checked the latest version (2.1.3) and I have some suggestions. In the CSS plugin: _createSVG = function (type, container, attributes) { var element = _doc.createElementNS("http://www.w3.org/2000/svg", type), reg = /([a-z])([A-Z])/g, p; for (p in attributes) { element.setAttributeNS(null, p.replace(reg, "$1-$2").toLowerCase(), attributes[p]); } container.appendChild(element); return element; }, It should be: _createSVG = function (type, container, attributes) { var element = _createElement(type, "http://www.w3.org/2000/svg"), reg = /([a-z])([A-Z])/g, p; for (p in attributes) { element.setAttributeNS(null, p.replace(reg, "$1-$2").toLowerCase(), attributes[p]); } container.appendChild(element); return element; }, and the _createElement: _createElement = function (type, ns) { var e = _doc.createElementNS ? _doc.createElementNS(ns || "http://www.w3.org/1999/xhtml", type) : _doc.createElement(type); return e.style ? e : _doc.createElement(type); //some environments won't allow access to the element's style when created with a namespace in which case we default to the standard createElement() to work around the issue. Also note that when GSAP is embedded directly inside an SVG file, createElement() won't allow access to the style object in Firefox (see https://greensock.com/forums/topic/20215-problem-using-tweenmax-in-standalone-self-containing-svg-file-err-cannot-set-property-csstext-of-undefined/). }, could be (if we presume, that this was the cause for others) : _createElement = function (type, ns) { return _doc.createElementNS ? _doc.createElementNS((ns || "http://www.w3.org/1999/xhtml").replace(/^https/, 'http'), type) : _doc.createElement(type); //Rarely servers replace the http:// into https:// which is not a proper namespace so we have to fix that. },

Well, I think I found something. Look: https://jsfiddle.net/wk3nyu8m/1/ For me in Chrome and Firefox there is the error in the console. The .style property is undefined (Do you see the same?) Then look at this: https://jsfiddle.net/wk3nyu8m/2/ It works for me just fine. Do you see the difference? https:// vs http:// in the namespace. The proper is http:// but on these servers, the server rewrote the http:// in the JS files to https:// (Might be a hosting provider setting...) Update: Yeah, this was the cause for both of our users. One was a Joomla and two was WordPress and they were nginx server.

Thanks, yeah it is weird. We use this version since a year and it was the third time in this month when we saw this error. (All of them were different WordPress or Joomla site.) Might be a Chrome only bug? If we would be able to find the cause, we might be able to report it to their developers. Several times in the past I experienced new "bugs" when I updated to newer version. Well, they were not bugs exactly, but what worked in the last version might produce error in the next It is not GSAP fault! I think the cause is that GSAP allows you to do a lot of things, even advanced, not documented things and 60fps and our eye might hinder bugs what we should see. When you you are dancing on the border bugs might happen. So, it takes several days of testing before I can safely upgrade GSAP (and under safely, I mean 90%, As I think you know it is really hard to test animations in the async environment (dropping framerate might cause bugs, etc...)). If I push out an update, that affects thousands of website in the first 24 hour, so the my responsibility is very high. Better to be safe than sorry.

We do not use the latest GSAP in our stable software. We use version 2.0.2. Several of our users reported that there is a JavaScript error in our application. The error was: TypeError: Cannot set property 'transformOrigin' of undefined We narrowed the problem to this: var Ja = O.documentElement || {}, Ka = function () { var a, b, c, d = p || /Android/i.test(T) && !_gsScope.chrome; return O.createElementNS && !d && (a = Ia("svg", Ja), b = Ia("rect", a, { width: 100, height: 50, x: 100 }), c = b.getBoundingClientRect().width, b.style[Ea] = "50% 50%", b.style[Ca] = "scaleX(0.5)", d = c === b.getBoundingClientRect().width && !(n && Fa), Ja.removeChild(a)), d }() I was able to find a GitHub ticket which probably related to this issue: https://github.com/greensock/GreenSock-JS/issues/288 @GreenSock So my real question is, that were you able to find why this issue happens on one website and why not on others? Do you know the real cause what goes wrong when you use .createElementNS why the style property is not accessible? If we would know, the we could reproduce the issue on our local test sites and we could verify if the latest GSAP works fine in that environment.

Thanks @GreenSock! And there is no chance that this._propLookup is array and GSAP reaches ._kill with that array right? I assume that this._propLookup was originally an array, which holds a lookup table for every animated elements in that tween. So if the same tween contains multiple path, the _proplookup looks like: [0: {... lookup table for element 1...}, 1: {... lookup table for element 2...}, ...], but there is an optimization when the tween contains only one element, then the array become object and holds the lookup table only for that element: {... lookup table for element 1...}. So probably every other usage of the lookup table gets only the object for a single element. Which means there would be no issue Ps.: For code maintaining purpose, maybe it would be better to make a single element to behave like there are multiple targets. That would free up several if statements, but on the other side you would get some loops if there is only one element. But it would help to reduce the codebase. I tried to simulate that situation, but there were no error with the latest beta version, so it seems fine with multiple targets too: https://codepen.io/mm00/pen/KLyLLv?editors=0010

Thanks @Dipscom, well, Joomla is not really related. The only thing which is related the Mootools changes the prototype of the Array. So placing the following before GSAP should be able to trigger this behavior. Array.prototype.test = function(){ } Well, finally I was able to reproduce it in Codepen https://codepen.io/mm00/pen/zQPBwQ?editors=0010 When the invalidate() call removed, the example works as expected. I need to call the invalidate() as in my example that timeline reinserted into new timelines all the time. @GreenSock: I changed the following in TweenLite: this._propLookup = []; To: this._propLookup = {}; and this._propLookup = (this._targets) ? {} : []; To: this._propLookup = {}; Everything seems to works normally. Also I tracked and this._propLookup only used as array when you loop through this._targets array, in those loops you use the this._targets.length, so the this._propLookup can be accessed in the object just fine.

Hi! Sadly, Joomla users still use Mootools 1.4.5 and there is a compatibility issue with GSAP. Mootools add functions to the prototype of the array, for example: Array.prototype.test = function(){ } var myArray = [1]; for(var k in myArray){ console.log(k) } /* Output: - 0 - test To get the proper output: */ for(var k in myArray){ if(myArray.hasOwnProperty(k)){ console.log(k) } } /* Output: - 0 */ So I was not able to reproduce this issue in Codepen as there should be something in my system which triggers the error, but here are the clues. The vars variable hold the array which looped through with for ... in. Probably vars should be object and you can safely use for ... in. Call stack: https://i.imgur.com/UwMyhlG.png ._kill https://i.imgur.com/p6zEyfg.png ._applyOverwrite: https://i.imgur.com/CXRmShX.png .initProps: https://i.imgur.com/OZakdII.png ._init: https://i.imgur.com/hnTSmnt.png vars holds the value of the this._propLookup which inited as array in .invalidate() and in TweenLite constructor.

I think this is what you need. Just move the container to the direction what you want and the inner part to the opposite direction with the same amount.

One more interesting fact. Math.round(v.toFixed(1)) is very slow compared to: Math.round(v) But The following gives the same result as Math.round(v.toFixed(1)) and runs as fast as Math.round() Math.round(((v * 10) | 0) / 10) https://jsbench.me/cajtgubfls/1

@GreenSock one extra question if you do not mind. What do you think why this rounding issue only happened with the drag interaction (Setting progress multiple time on a paused timeline and then play) and does not ever happened with with simple play of the timeline? Is there any rare correlation what you can think of? Is it possible for example that click event happens exactly at a tick while mousemove and the mouseup not snapped to the tick?

Finally the solution With modifiers plugin, I was able to achieve the desired result with: { x: 0, modifiers: { x: function (x) { return Math.round(x.toFixed(1)); } } }

Yeah, it would be worst by turning roundProps off. There would be lines between every boxes. (Probably I had that floating point conversation few months ago which you remember: https://greensock.com/forums/topic/19625-addpause-the-behavior-is-unexpected/?tab=comments#comment-91640) Here my further findings. 1-3 boxes pt.c = -1200 v = 0.18125000000000002 pt.s = 1200 = 982.5 rounded -> 983 3-6 boxes pt.c = -1200 v = 0.18125000000000002 pt.s = 0 = -217.50000000000003 rounded -> -218

Well, It happens on my FHD and also on the WQHD monitor. I was not able to test it on HiDPI. My computer is pretty fast, latest I7 and there is no FPS drop when it happens. I wouldn't think it is sub pixel misalignment as I use GSAP roundProps, so the x values always integers. I created a timestamp for the performance record which displays the X values get written by GSAP: I think the problem lies here. The first three bar is the X value for the first 3 box and the last 3 bar is for the last 3 box. The sum of any first box and any last box should give 1200px in every frame. In frame before the frame with the vertical line, the math does not work. GSAP calculates 829 and 372 which gives 1201 so there was a miscalculation and this cause the gap between those two.