fix(tests): drain view transition state between transition helper tests - #309
Merged
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
transition helpersuite intest/spec/html.jsfails on WebKit withExpected spy warn to have been called 2 times. It was called 1 times., which currently blocks CI on unrelated pull requests. Theshould render componenttest starts a real view transition but only waits 200ms viaresolveTimeout, so it never waits for that transition to settle. Sincesrc/template/helpers/transition.jskeeps the current transition in module scope astransition.instance, the unfinished transition leaks into the next test.That leakage is what made the following test observe two warnings: with a transition still in progress, both rendered elements hit the "already in progress" branch. Without the leak the correct, deterministic result is one warning, because the first element starts the transition and only the second one hits that branch. Chrome and Firefox happened to still be mid-transition and passed by accident, while WebKit settles the transition faster and produced the real count.
This drains the pending transition in
afterEachby awaitinghtml.transition.instance.finished, so each test starts from a clean state, and updates the expectation to the deterministic value of one warning. The assertion now verifies exactly what the test name describes rather than relying on cross-test state. No library source is changed.Verified locally on Chrome (579/579 passing); WebKit headless does not launch on macOS, so CI covers that browser.