Bug 49182 – animations/stop-animation-on-suspend.html sometimes fails on all platforms

• Component: Layout and Rendering
• Status: REOPENED

[Adam Roben (:aroben)]

animations/stop-animation-on-suspend.html sometimes fails on Windows. See the URL for one example. Here's another:

http://build.webkit.org/results/Windows%20Debug%20(Tests)/r71518%20(22136)/animations/stop-animation-on-suspend-pretty-diff.html

I've added this test to the Skipped file.

[Adam Roben (:aroben)]

I think this has been happening since the test was added in r71424. It looks like r71454 tried to address some of the failures, but clearly there are still problems.

[Adam Roben (:aroben)]

<rdar://problem/8641506>

[Eric Seidel (no email)]

animations/stop-animation-on-suspend.html is flaky on all platforms.  We should skip it.

[Eric Seidel (no email)]

Skipped for now:

Committed r73175: <http://trac.webkit.org/changeset/73175>

[WebKit Review Bot]

http://trac.webkit.org/changeset/73175 might have broken SnowLeopard Intel Release (Tests)
The following tests are not passing:
fast/profiler/throw-exception-from-eval.html

[Eric Seidel (no email)]

Um... The sherrifbot is right.  But it makes no sense.
http://trac.webkit.org/browser/trunk/LayoutTests/fast/profiler/throw-exception-from-eval.html
is now failing.  Perhaps it was dependent on this earlier test?

[Eric Seidel (no email)]

I wonder if this could have been caused by the rollout of bug 50401.

[Adam Klein]

This test has been skipped for >1 year on most platforms (on Chromium, we run it but expect it to fail flakily). Perhaps it's time to delete the test?

[Simon Fraser (smfr)]

..or fix it.

[Dominik Röttsches (drott)]

*** Bug 84592 has been marked as a duplicate of this bug. ***

[Dominik Röttsches (drott)]

Jussi writes in bug 84592:
"I believe the "webkitAnimationStart" event on document and the one on iframe happen at different times, but the test starts a single timer (on documents event) and of course the the iframe animation isn't synced"

[Jussi Kukkonen (jku)]

(In reply to comment #11)
> Jussi writes in bug 84592:
> "I believe the "webkitAnimationStart" event on document and the one on iframe happen at different times, but the test starts a single timer (on documents event) and of course the the iframe animation isn't synced"

I could try doing something on this, but I'm not sure what the correct assumptions are:
The test assumes that 'box' and  'subframe-box' (inside the iframe) start animating at the same time. This isn't currently true, it seems 'subframe-box' is not even in the dom tree when 'box' animation starts.

If we don't care about animations starting (roughly) at the same time, I could probably just modify the test to ensure that both animations do suspend and resume.

[Jussi Kukkonen (jku)]

(In reply to comment #12)
> If we don't care about animations starting (roughly) at the same time, I could probably just modify the test to ensure that both animations do suspend and resume.

I did just that and realised suspendAnimations() does not actually work. I'm pretty sure it did when I originally looked at this (in the duplicate bug). It's posisble we've missed a regression because this was skipped. I will take a closer look but comments on the assumption in comment 11 are still welcome.

[Jussi Kukkonen (jku)]

(In reply to comment #13)
> I did just that and realised suspendAnimations() does not actually work. I'm pretty sure it did when I originally looked at this (in the duplicate bug). It's posisble we've missed a regression because this was skipped. I will take a closer look but comments on the assumption in comment 11 are still welcome.

Oh that was was silly of me -- I didn't notice it was a Internals call. Apologies for the spam.

I'll upload a patch that modifies this test to not expect animations to start at the same time and improves the documentation a bit -- there's a test for stopping on suspend already, this was added to make sure animations in subframes stop as well.

[Jussi Kukkonen (jku)]

Created attachment 171837 [details]
Patch

[Jussi Kukkonen (jku)]

(In reply to comment #15)
> Created an attachment (id=171837) [details]

Timing things like this in js is inherently flaky, but I think this should now be as good as the other tests (like suspend-resume-animation) although I'll take suggestions on a better way to do this than the iframe onload handler.

I've removed the failure expectations for this on all ports (except chromium who also had a crash expectation?) please let me know if you'd rather I didn't do that.

[Antti Koivisto]

Comment on attachment 171837 [details]
Patch

r=me

[WebKit Review Bot]

Comment on attachment 171837 [details]
Patch

Clearing flags on attachment: 171837

Committed r135307: <http://trac.webkit.org/changeset/135307>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

Re-opened since this is blocked by bug 102905