Check out that branch I just sent a PR from @chadparry - let me know if it fixes your issue. Also - that unit test fails against current build but passes in new build.

It wouldn't be the worst thing to consolidate fxNow and fxTickNow. I was worried that when jQuery.fx.tick clobbers the old timestamp, it may break animations that were supposed to be synchronized. Suppose that one animation started, then jQuery.fx.tick was called, then in the same frame another animation was started. The second animation would end up with a different start time from the first. My use of two timestamp variables prevents that confusion.

Although, now I don't see how jQuery.fx.tick could ever be called in the same JS frame as anything else. It is always called from its own setInterval. Is it considered part of the public API, so users could potentially request a tick on demand? I don't see it documented anywhere. If it is considered private, then I can remove fxTickNow and we'll have nothing to worry about.

@chadparry If someone were to call jQuery.fx.tick() directly, I would think this should start a new "frame" of animation regardless of it it was in the same JavaScript event loop. See gh-1022 😺 - I wrote that to show the cleaner test case that actually fails in the old code, but passes in the new.

You're right. Your patch is simpler. Sorry I wasn't able to be more helpful.

Thanks for the quick turnaround!