Summary: | animations/stop-animation-on-suspend.html sometimes fails on all platforms | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Adam Roben (:aroben) <aroben> | ||||
Component: | Layout and Rendering | Assignee: | Chris Marrin <cmarrin> | ||||
Status: | REOPENED --- | ||||||
Severity: | Normal | CC: | abarth, adamk, ap, cmarrin, d-r, eric, gyuyoung.kim, jonlee, jussi.kukkonen, rakuco, simon.fraser, webkit.review.bot | ||||
Priority: | P2 | Keywords: | InRadar, LayoutTestFailure | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
URL: | http://build.webkit.org/results/Windows%20Debug%20(Tests)/r71517%20(22135)/animations/stop-animation-on-suspend-pretty-diff.html | ||||||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=206667 https://bugs.webkit.org/show_bug.cgi?id=184580 https://bugs.webkit.org/show_bug.cgi?id=190032 |
||||||
Bug Depends on: | 102905 | ||||||
Bug Blocks: | 49179, 43905 | ||||||
Attachments: |
|
Description
Adam Roben (:aroben)
2010-11-08 08:56:12 PST
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. animations/stop-animation-on-suspend.html is flaky on all platforms. We should skip it. Skipped for now: Committed r73175: <http://trac.webkit.org/changeset/73175> 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 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? I wonder if this could have been caused by the rollout of bug 50401. 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? ..or fix it. *** Bug 84592 has been marked as a duplicate of this bug. *** 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" (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. (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. (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. Created attachment 171837 [details]
Patch
(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. Comment on attachment 171837 [details]
Patch
r=me
Comment on attachment 171837 [details] Patch Clearing flags on attachment: 171837 Committed r135307: <http://trac.webkit.org/changeset/135307> All reviewed patches have been landed. Closing bug. Re-opened since this is blocked by bug 102905 |