Skip to content

Conversation

@birtles
Copy link
Contributor

@birtles birtles commented Oct 25, 2024

Fixes #11084.

@birtles
Copy link
Contributor Author

birtles commented Oct 25, 2024

WPT will be added in https://bugzilla.mozilla.org/show_bug.cgi?id=1917071

@birtles birtles force-pushed the flush-after-commit-styles branch from e24222b to 5212614 Compare October 25, 2024 02:06
@andruud
Copy link
Member

andruud commented Nov 4, 2024

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.

@birtles
Copy link
Contributor Author

birtles commented Nov 11, 2024

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?

calling this method <em>does</em> trigger a [=style change event=]
(see [[#model-liveness]]).

Furthermore,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[web-animations-1] commitStyles followed by cancel should not trigger a transition

3 participants