[web-animations-1] Require a style flush at the end of commitStyles #11085
Conversation
|
WPT will be added in https://bugzilla.mozilla.org/show_bug.cgi?id=1917071 |
birtles
force-pushed
the
flush-after-commit-styles
branch
from
e24222b
to
5212614
Compare
|
Ah. In that case, maybe the example I wrote in this PR isn't so meaningful, since commitStyles won't trigger a transition for a separate and more specific reason. |
@andruud, I think @flackr was suggesting that with #6688 this PR wouldn't be needed. Is that right? |
| @@ -4877,6 +4877,22 @@ The {{Animation}} interface {#the-animation-interface} | |||
| calling this method <em>does</em> trigger a [=style change event=] | |||
| (see [[#model-liveness]]). | |||
|
|
|||
| Furthermore, | |||
There was a problem hiding this comment.
For this to work, do we not also have to require that both style flushes during commitStyles are part of the same style change event? Otherwise, transitions will be generated by the second flush?
There was a problem hiding this comment.
Not with the current setup. Either the animation is still applying in which case the changes to the inline style should be masked by the animation and no transition is generated, or the animation is not applied and commitStyles does nothing. Furthermore, the Gecko implementation of this PR passes all existing tests. Do you have any content in mind where a transition would be generated?
After #5394 is addressed we'd have to make sure that the first flush uses the non-endpoint exclusive timing but I think otherwise it works. (There may be some cases of layering animations where the result differs, however, I'm not sure.)
I think if we merge #6688 then this PR will not be needed but we'd need to do something else to address #5394.
Fixes #11084.