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

Handle null effect when interrupting a transition #18428

Merged
merged 1 commit into from Aug 14, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
38 changes: 38 additions & 0 deletions css/css-transitions/CSSTransition-effect.tentative.html
Expand Up @@ -10,6 +10,12 @@
<script>
'use strict';

function singleFrame() {
return new Promise((resolve, reject) => {
requestAnimationFrame(resolve);
});
}

test(t => {
const div = addDiv(t);
div.style.left = '0px';
Expand Down Expand Up @@ -87,6 +93,38 @@
assert_equals(getComputedStyle(div).left, '0px');
}, 'After setting a transition\'s effect to null, a new transition can be started');

// This is a regression test for https://crbug.com/992668, where Chromium would
// crash if the running transition's effect was set to null and the transition
// was interrupted before it could finish due to the null effect.
promise_test(async t => {
const div = addDiv(t);
div.style.left = '0px';

div.style.transition = 'left 100s';
getComputedStyle(div).left;
div.style.left = '100px';

assert_equals(div.getAnimations().length, 1);

const transition = div.getAnimations()[0];
await transition.ready;

// The transition needs to have a non-zero currentTime for the interruption
// reversal logic to apply.
await singleFrame();
assert_not_equals(transition.currentTime, 0);
assert_not_equals(getComputedStyle(div).left, '0px');
Copy link
Contributor

Choose a reason for hiding this comment

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

@stephenmcgruer This test is failing on Firefox because it produces '0px' here. I don't think there's anything in the spec requiring that it have moved past 0px by this point (e.g. due to pixel rounding).

Based on the comment above this block I don't believe this assertion is needed (only the first one is). Would you mind dropping it?

If it is needed, would you mind reworking the test to wait until the value of left is actually non-zero?

Thanks.

Copy link
Contributor

Choose a reason for hiding this comment

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

Argh, sorry, you're totally right. That's what I get for being lazy and not testing on Firefox, sorry.

I'll fix this tomorrow when I get to work. It's a bit weird because its really a regression test for Chromium, but we're meant to land all tests as WPT these days so I try to at least make them applicable to all browsers (e.g. test some real behavior). The test should wait until left is non-zero.


// Without yielding to the rendering loop, set the current transition's
// effect to null and interrupt the transition. This should work correctly.
transition.effect = null;
div.style.left = '0px';

// Yield to the rendering loop. This should not crash.
await singleFrame();
}, 'After setting a transition\'s effect to null, it should be possible to '
+ 'interrupt that transition');

promise_test(async t => {
const div = addDiv(t);
div.style.left = '0px';
Expand Down