WebKit export of https://bugs.webkit.org/show_bug.cgi?id=170784 #11266
Conversation
|
We can't write this as a scripted test that just compares the values returned by (I'm concerned that this test will become flaky, or simply useless because on our CI we often can have tens of seconds between animation frames when the test machine is under load whereas this test seems to be dealing with changes in hundreds of milliseconds.) |
I agree flakiness is a potential issue, that's why the test is not too strict: the animation not too fast and the covering rect is wider than the animated squares. I initially tried doing getComputedStyle() but the issue is that the visual rendering does not necessary match the value returned from the DOM. In this particular WebKit iOS bug, the UI Process continues to animate the squares while the Web process claims they are paused. |
|
Looks like the test fails on Firefox. https://travis-ci.org/web-platform-tests/wpt/jobs/386104808#L793-L798 |
|
OK, it worked for me locally but probably this is because the test is flaky. I think I can verify getComputedStyle() to make the test a bit more robust and also fire the pause in a small interval around the target time instead of only after it. |
- Increase the height of covering rect to avoid anti-aliasing issue with the red squares. - Instead of waiting a delay, use the shift returned by getComputedStyle() to know when animated squares are supposed to be hidden by the green rect. - Instead of waiting an additional amount of time to ensure red squares will show up again if they were not paused, just use the animation duration to decide when the screenshot should be taken.
|
@birtles What do you think of this new version? The parsing of window.getComputedStyle(...).transform is not really nice and the minimum duration is now always 2s but at least the whole thjing should be more accurate than relying on timestamp. |
|
It's failing again under Firefox Nightly, but I'm not able to reproduce the issue locally. Is there a way to get the screenshots from travis? Otherwise, I guess I should send the test to the Mozilla try sever... |
|
@birtles css/css-animations/set-animation-play-state-to-paused-001.html passes in Try server, so probably it's an issue with the Travis WPT bot: |
@fred-wang That appears to be failing pretty consistently in the try run you linked to. |
|
@birtles /set-animation-play-state-to-paused-002.html is failing, not /set-animation-play-state-to-paused-001.html |
|
. |
WebKit export from bug: [iOS] Animations with Bézier timing function not suspended on UI process when animation-play-state is set to "paused"