BaskingShark

Since I'm importing the NPM package it's hard for me to switch over to test that beta, but looks to me like making sure "e !== _docElement" should do it. Thanks for patching that up!

Thanks for the info! That's good detail to know and I'll keep it in mind as I'm building animations. Should I look for a patch in a future version or is this too much of an edge case and I should modify my existing timelines that touch the html element?

Hi Jack, Yes, this is only a problem when changing a class on the html element as part of a timeline. I admit it's a rare case and I can go through my code and work around it now that I've identified the issue, but it is an unintentional breaking change from 2.0.x to 2.1.x and after a good part of a day trying to track down what was going on it might be something you either want to patch or that other people could encounter and need to know to avoid. I'm surprised to hear you don't recommend changing classes in timelines since I hadn't read anything about it being a performance problem or a discouraged feature. I use that technique fairly frequently (although not on the html element) to keep changes to the DOM display in sync with animations. For example, switching tabs where a single timeline has a fade out animation, a class change to adjust layer stacking, hidden elements, pointer-events, etc., then another animation to fade in the new content. Are class changes in a timeline something to actively avoid? As for changing classes on the html element, as I said, it's rare but I have a couple of cases where I need to make some global change to all elements on a page in sync with an animation. For example, I have a waiting indicator that appears when changes are being saved to the backend. I animate it in while setting a class on the HTML tag that fades and locks all buttons and form fields on the page. When the API returns successfully, I animate out the waiting indicator and remove the "waiting" class to restore editing. I have something similar for animated popup boxes that require a modal state preventing interactions and animations from running beneath the popup. Setting the class within the timeline in those cases is just a convenience and I can easily move the action to a separate line outside of TimelineLite, but since I've been used to doing things like "+=waiting" in set() if I'm already running a timeline, I just kept up with the practice. Thanks!

The update to 2.1.x started throwing errors in several spots in my project so I rolled back until I could get a chance to debug what was different. I finally worked out what the problem is: you can no longer change a class on the HTML element as part of a timeline. This seems to be a change in CSSPlugin.js that pushes every call to the set() function in TimelineLite through the "_getMatrix" function. That function performs a trick when the element isn't visible by appending the element to the DOM. Unfortunately, if the target is the HTML element that causes a "DOMException: Failed to execute 'appendChild' on 'Node': The new child element contains the parent" error. Line 1366 ends up trying to append the HTML element to the HTML element. I can see that v.2.0.2 didn't call "_getMatrix" at all on set() and definitely not for a simple class addition or removal. Here's an example that will break every time: const waitContainer = $('.waiting_container'); const waitEnd_tl = new TimelineLite() .to(waitContainer, 0.2, {opacity: 0, ease: 'easeOut'}) .set($('html'), {className: '-=waiting'}); If you run the CodePen in debug view, you'll get the error after 2 seconds.

While i absolutely agree this is sloppy syntax — the result of weeks of editing and re-edting a massive web app — it’s also a structure that was fully supported until this point release. And one that works with the aim of autoCSS to provide a shortcut for frequently animated css properties. It seems to me that either the documentation needs to be updated to explicitly warn against mixing css and autoCSS properties, or the code needs to continue to support a combination within a single statement as it has until 1.19.1. I just figure that if this situation showed up for me and broke a fully tested web app, then it’s bound to hit other people as well and similarly mystify them.

OK, I finally tracked down the bug and modified my original Codepen to demo it. The issue is with the updated _addPropTween function on TweenMax's line 6984. It's an obscure one for sure: When you set opacity on an element and also set a css class, like var tl = new TimelineMax().set(obj, {opacity: 0, css: {className: '+=active'}}); the new _addPropTween function mistakenly adds opacity to that DOM element's properties. Then if that element is tweened later on and opacity is one of the css properties being manipulated, TweenMax's line 6866 if (!_reservedProps[p] && (!(p in target) || p === "transform" || p === "x" || p === "y" || p === "width" || p === "height" || p === "className" || p === "border") && (!_plugins[p] || (_plugins[p] && _plugins[p]._autoCSS))) finds opacity in the target and doesn't add it to vars.css. It gets skipped. Maybe this is now the desired behavior? I tend to think that adding a non-standard property to a DOM element is probably going to cause other problems down the line, like it did in my case. Whew! That was a monster to find.

I've seen the same behavior on macOS 10.12.3 with both Chrome 56.0.2924.87 and Firefox 51.0.1. Thanks!

Just ran a test and will-change doesn't make a difference in the opacity bug -- it still skips that portion of the CSSPlugin code -- but autoAlpha works in either case. I'll stick with that. Still, I'm removing that will-change and a few others; thanks! The way that browsers are now implementing that property makes it far less useful than it used to be for improving performance. It's moved from a useful hint to toss elements over to the GPU for faster processing to one that acts more like an !important flag for browser rendering... not terribly helpful in most cases.

OK, this is good: while immediateRender:false doesn't help, autoAlpha seems to work under both 1.19.0 and 1.19.1! When I watch for DOM attribute modification, the first break in JS with autoAlpha under 1.19.1 happens at the same point as that for opacity under 1.19.0: line 2611 in CSSPlugin. It seems that the problematic pathway through that plugin is corrected with autoAlpha and the opacity portion of the tween is no longer skipped. I think there's a deep, obscure bug somewhere in TweenMax relating to skipping opacity, but it seems it can be bypassed with autoAlpha. I can run identical code under 1.19.0 and 1.19.1 with the only difference being "opacity" or "autoAlpha" -- the first jumps past the opacity tween code, the second activates it. I wish I could isolate the problem in a Codepen since I'm sure other people could benefit if the root cause could be found, but for now this solves the issue and lets me keep working. Thanks!!

Yeah, I know it's not helpful to be unable to duplicate it in a CodePen, but I'm hoping that one of the developers can think of the possible triggers for skipping opacity in a tween and if any of those changed in this TweenMax update. I've simply run out of ideas on what is causing it to skip that portion of the code since it doesn't seem to be either the CSS or the immediate JS. Since there are thousands of lines of Javascript that make up the entire web app, I'm hoping for a hint about other places to look for what could be the cause. Thanks for checking!

I'm looking for any suggestions as to what might cause the bug I'm currently experiencing in TweenMax 1.19.1 -- I've run out of ideas. Here are the basics: I'm doing a TweenMax.staggerFromTo transformation that simply moves several elements from -20px and 0 opacity to 0px and 1 opacity. The classic "fade in from the left." The animation runs perfectly except that, with the most recent update to TweenMax, the opacity portion of the tween is being skipped altogether. The opacity of the elements is never modified and, even with clearProps not being used, opacity is not left in the Styles attribute after the transformation. The result is that the elements appear on the screen, then move 20 pixels to the right in sequence with no fade in. Some additional information: This bug appears in 1.19.1 only. I can switch back to TweenMax 1.19.0 and it won't appear, switch again to 1.19.1 and it will. So it's something that changed between this version and the last. I've tested in on Chrome and Firefox so it isn't just a single browser. While I've copied the basic situation in a Codepen, I cannot seem to reproduce the bug. There's a lot going on on this page, but no other modifications to this element take place before the Tween with the problem. I've tried adding every CSS attribute assigned to the real element to the Codepen element and I've reproduced the nested function/promise/function structure of the js, but I can't get the issue to appear. The attached pen does show the context, at least. If I set the debugger to break on attribute modification, in 1.19.0 it breaks first on the opacity part of CSSPlugin.js at line 2611. In 1.19.1 it breaks on the matrix portion of CSSPlugin.js at line 1722, skipping the opacity code entirely. If I try to modify only the opacity and not the position, it does nothing at all and no attributes are modified on that element. It's definitely only the opacity tween that's affected. Any thoughts on what has changed in 1.19.1 that could lead to opacity being skipped in a staggerFromTo under certain conditions? I'd prefer not to have to freeze Greensock updates on this project and stay with 1.19.0 for good, but I've spent more than a day on this and I still can't figure out what might be causing this deeply obscure problem.