I can see that commenting out the scrollY line changes behavior.

Setting component to Animation for further triage.

I updated the fiddle: https://jsfiddle.net/fnL428zq/5/

In this fiddle you can see that window.scrollY interferes in the forced redraw - making the transition not work. When using it with setTimeout the redraw occurs as expected.

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #69.0.3497.100 and latest canary #71.0.3572.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

I tried this on Linux, firefox doesn't work even with commenting the window.scrollY line.

There is a race condition here.

case 1: 
"slide--up-enter" and "slide--up-enter-active" added in same frame.

result 1: 
Rules for the second class stomp rules from the first and there is no animation since the box is already in the correct position.

case 2:
"slide--up-enter-active" added after the frame draw, but before the animation ticks.

result 2:
The first animation is canceled and second starts. This is what triggers the "expected" jump.

case 3:
First animation starts and ticks before second animation takes effect.

result 3:
Animation transitions from first to the second.  Instead of a jump, and small blip is observed.

The behavior appears to be in agreement with the spec for transform animations (https://drafts.csswg.org/css-transforms/#interpolation-of-transforms). In this case, the rules are set up in an ill-conditioned manner. The recommended approach to synchronize rendering is via RequestAnimationFrame. Forcing a layout by fetching a layout-dependent property or introducing a short delay via a setTimeout call is not guaranteed to produce consistent rendering effects.

Thanks for the detailed response, but if I got it right, the following fiddle would remove the race condition: https://jsfiddle.net/fnL428zq/14/

But the desired result is still not the expected.

From my understanding I got around the race condition by using a nested requestAnimationFrame call, forcing it to be called on next repaint/animation tick.

I believe the following will produce the intended effect consistently on Chrome and Firefox:

function initAnimation() {
  const node = document.createElement("div");
  node.classList.add("test");
  document.body.appendChild(node);
  requestAnimationFrame(() => {
    node.classList.add("slide--up-enter");
    requestAnimationFrame(() => {
      node.classList.add("slide--up-enter-active");
    })
  });
}