CSS transition ignored when adding element to DOM and animating after requestAnimationFrame

RESOLVED INVALID

Status

()

Core
CSS Parsing and Computation
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: mikehenrty, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

If I add an element to the DOM and then change a css property with a transition to that element on the next animation frame, the transition is ignored in gecko. The animation is not ignored in the latest blink or webkit it seems. Oddly, using setTimeout instead of requestAnimationFrame below 10ms doesn't work most of the time, but above 10ms it seems to always animate. Pasting test case below.


Test case:

<!doctype html>
<html>
<head>
  <style>
    .progress {
      background-color: blue;
      height: 10px;
      width: 0%;
      transition: width linear 2s;
    }
    .progress.full {
      width: 100%;
    }
  </style>
</head>
<body>
  <button id="button">Add</button>
  <script>

    var button = document.getElementById('button');

    button.onclick = function() {
      var progress = document.createElement('div');
      progress.classList.add('progress');
      document.body.appendChild(progress);
      // add transition triggering animation on next frame
      requestAnimationFrame(function() {
        progress.classList.add('full');
      });
    };

  </script>
</body>
</html>
:dbaron, is this related to bug 625289?
Flags: needinfo?(dbaron)
I don't think it's related; I also wouldn't have expected it to work.  Why should we have computed style by the time the requestAnimationFrame callback has happened -- it's there so that script can do things before the work we do in that refresh tick happens, right?
Flags: needinfo?(dbaron)
(It would be interesting to know why it works in Blink and WebKit, certainly.)
(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #2)
> I don't think it's related; I also wouldn't have expected it to work.  Why
> should we have computed style by the time the requestAnimationFrame callback
> has happened -- it's there so that script can do things before the work we
> do in that refresh tick happens, right?

Hmm, my thought was that the page would not repaint (and thereby call the requestAnimationFrame callback) until the new element was added to the layout and rendered to the screen. Would you say this bug is invalid then?

Also, do you know if there is a preferred way to add an element to the screen and then animate it? It seems right now the amount of time you have to wait after adding an element to the DOM before changing a css property to get a transition to trigger is ~10ms. But it is indeterminate.
Flags: needinfo?(dbaron)
> Hmm, my thought was that the page would not repaint (and thereby call the
> requestAnimationFrame callback)

The callback happens _before_ the repaint.  That's the whole point.

> Would you say this bug is invalid then?

Imo, yes.

Note that there is a movement to actually specify this stuff; we'll see how that goes.

> Also, do you know if there is a preferred way to add an element to the screen and then 
> animate it?

The simplest way is to add it, then wait two rAF ticks.
Thanks for the info David and Boris.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(dbaron)
Resolution: --- → INVALID
I still think it's worth figuring out why this works in Blink and WebKit.
Blink used to have a style recomputation timer independent of requestAnimationFrame, as far as I know.  WebKit might still have that...
That makes sense, at least if it's still true for both Blink and WebKit.
It's not longer entirely true for Blink; I can't quite figure out what their new setup looks like and how things are ordered in it.
You need to log in before you can comment on or make changes to this bug.