The throttled animations/transitions might be not synced with those on the compositor, especially when we replace a running transform transition on the compositor. There are 2 possible issues per hiro mentioned in Riot:

1. we don't want to flush throttled animations in cases of mouse movement or some such
2. we do want to flush throttled animations when the target animating element is dirty.

And for 1), there is an which causes some crashes when hiro hacked it:

hiro: and for 1) I vaguely remember when I tried to remove the flush, there were crash bugs during stylo development that is that the dirty style bit for the element remains after traversal, and there was(is?) an assertion checking it after traversal.
the assertion I mean, MOZ_RELEASE_ASSERT. it might be a relaxed one. DIAGNOSTIC? I don't remember the exact name.

So perhaps we should try 2) or any other way to avoid the mouse event from flushing the throttled animations?

We notice this issue when debugging Bug 1623425 after applying the patches of Bug 1626165.

Hi Emilio, I file this bug for more discussion or any possible solution for Bug 1626165 Comment 10.

Note: hiro mentioned the flush comes from https://hg.mozilla.org/mozilla-central/rev/1bc40cb5b27c9055d00f6ff17a63231587677aec, which then was turned on to a more-specific thing for https://hg.mozilla.org/mozilla-central/rev/1c63f67bbaf1

However, I'm not familiar with the area, so perhaps I need more feedbacks.

I'd try to remove the flush if possible. Chances are it's not necessary anymore. I think the intention of the layout flush was that you hit with the mouse what you actually see on the screen. But throttled animation flush doesn't update layout so I'm not sure it works as intended anymore?

If it works somehow (I'd guess because most, but not all, of the transforms code runs during painting, and we may use a hit-test for that), then I'd try to make it a regular style flush (which should do the right thing here, right?). We have faster styling now and the complexity of flushing only animations in this way, and trying to mess with the style system dirty tracking is probably not worth it.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

If it works somehow (I'd guess because most, but not all, of the transforms code runs during painting, and we may use a hit-test for that)

I presume if there are corner cases where hit-test doesn't work, it could be somehow make the cases work via APZ. As you know, nowadays hit-test for OOP iframes replies on APZ.

then I'd try to make it a regular style flush (which should do the right thing here, right?). We have faster styling now and the complexity of flushing only animations in this way, and trying to mess with the style system dirty tracking is probably not worth it.

We've already flushed normal pending styles just before we try to flush throttled animations. You may want to say it's messy. :)

The severity field is not set for this bug.
:svoisen, could you have a look please?

For more information, please visit auto_nag documentation.