Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-transitions-2] Make null-effect test properly wait for the transition to start #18457

Merged
merged 1 commit into from Aug 16, 2019

Conversation

@stephenmcgruer
Copy link
Contributor

stephenmcgruer commented Aug 15, 2019

Previously this test would just rAF a single frame and assume that the
transition had started and that the 'left' had changed. Instead, this PR
changes the test to explicitly wait for 'left' to change, so that we can
be sure the transition has started before we interrupt it.

…ition to start

Previously this test would just rAF a single frame and assume that the
transition had started and that the 'left' had changed. Instead, this PR
changes the test to explicitly wait for 'left' to change, so that we can
be sure the transition has started before we interrupt it.
@wpt-pr-bot wpt-pr-bot requested a review from dbaron Aug 15, 2019
@stephenmcgruer stephenmcgruer requested review from birtles and removed request for dbaron Aug 15, 2019
@stephenmcgruer
Copy link
Contributor Author

stephenmcgruer commented Aug 15, 2019

Hey Brian, PTAL.

Interestingly the test before this one, "After setting a transition's effect to null, a new transition can be started", also fails on Firefox. This appears to be because there's a difference in expectations between Chrome and Firefox as to what the new transition's 'from' value should be. If one adds a few rAFs at the end of the test, you can see the difference more clearly:

Chrome: FAIL After setting a transition's effect to null, a new transition can be started assert_equals: expected "0px" but got "0.0813531px"

Firefox: FAIL After setting a transition's effect to null, a new transition can be started assert_equals: expected "0px" but got "100.033px"

So Chrome is starting the new transition from 0, whereas Firefox starts it from 100px. I would suspect Firefox is correct, but haven't checked the spec yet.

@wpt-pr-bot
Copy link
Collaborator

wpt-pr-bot commented Aug 15, 2019

There are no reviewers for this pull request. Please reach out on W3C's irc server (irc.w3.org, port 6665) on channel #testing (web client) to get help with this. Thank you!

@birtles
Copy link
Contributor

birtles commented Aug 15, 2019

Hey Brian, PTAL.

Looks good. Thanks!

Interestingly the test before this one, "After setting a transition's effect to null, a new transition can be started", also fails on Firefox. This appears to be because there's a difference in expectations between Chrome and Firefox as to what the new transition's 'from' value should be. If one adds a few rAFs at the end of the test, you can see the difference more clearly:

Chrome: FAIL After setting a transition's effect to null, a new transition can be started assert_equals: expected "0px" but got "0.0813531px"

Firefox: FAIL After setting a transition's effect to null, a new transition can be started assert_equals: expected "0px" but got "100.033px"

So Chrome is starting the new transition from 0, whereas Firefox starts it from 100px. I would suspect Firefox is correct, but haven't checked the spec yet.

Yeah, I agree, I'm pretty sure it should start from 100px. Perhaps Chrome doesn't flush style for one of the calls to getAnimations().

Are you able to check what Chrome is doing and fix the test if necessary?

@stephenmcgruer
Copy link
Contributor Author

stephenmcgruer commented Aug 16, 2019

Are you able to check what Chrome is doing and fix the test if necessary?

Yes, I'll look into this.

@stephenmcgruer stephenmcgruer merged commit 386d028 into web-platform-tests:master Aug 16, 2019
10 of 11 checks passed
10 of 11 checks passed
update-pr-preview
Details
Azure Pipelines Build #20190815.128 succeeded
Details
Azure Pipelines (./wpt test-jobs) ./wpt test-jobs succeeded
Details
Azure Pipelines (affected tests without changes: Safari Technology Preview) affected tests without changes: Safari Technology Preview succeeded
Details
Azure Pipelines (affected tests: Safari Technology Preview) affected tests: Safari Technology Preview succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests) wpt.fyi hook: safari-preview-affected-tests succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests-without-changes) wpt.fyi hook: safari-preview-affected-tests-without-changes succeeded
Details
Taskcluster (pull_request) TaskGroup: success
Details
wpt.fyi - chrome[experimental] Chrome results
Details
wpt.fyi - firefox[experimental] Firefox results
Details
wpt.fyi - safari[experimental] Safari results
Details
@stephenmcgruer stephenmcgruer deleted the stephenmcgruer:fix-CSSTransition-effect.tentative.html-firefox branch Aug 16, 2019
@stephenmcgruer
Copy link
Contributor Author

stephenmcgruer commented Aug 16, 2019

Are you able to check what Chrome is doing and fix the test if necessary?

Having looked into it briefly, I believe this should be fixed by Kevin's in-progress refactor of our Animation class to (more) properly match the spec: https://chromium-review.googlesource.com/c/chromium/src/+/1739386 . So I'm going to wait for that to land and verify once it has done so.

@birtles
Copy link
Contributor

birtles commented Aug 17, 2019

Ok, thanks @stephenmcgruer!

natechapin added a commit to natechapin/wpt that referenced this pull request Aug 23, 2019
…ition to start (web-platform-tests#18457)

Previously this test would just rAF a single frame and assume that the
transition had started and that the 'left' had changed. Instead, this PR
changes the test to explicitly wait for 'left' to change, so that we can
be sure the transition has started before we interrupt it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.