and transitions/negative-delay.html fails intermittently: --- /home/webkitbuildbot/slaves/release64bitWebKit2_EC2/buildslave/qt-linux-64-release-webkit2/build/layout-test-results/transitions/negative-delay-expected.txt +++ /home/webkitbuildbot/slaves/release64bitWebKit2_EC2/buildslave/qt-linux-64-release-webkit2/build/layout-test-results/transitions/negative-delay-actual.txt @@ -1,9 +1,13 @@ -PASS - "left" property for "square1" element at 0s saw something close to: 300 +CONSOLE MESSAGE: line 240: Failed to pause 'left' transition on element 'square1' +CONSOLE MESSAGE: line 240: Failed to pause 'left' transition on element 'square1' +CONSOLE MESSAGE: line 240: Failed to pause '-webkit-transform' transition on element 'square3' +CONSOLE MESSAGE: line 240: Failed to pause '-webkit-transform' transition on element 'square3' +FAIL - "left" property for "square1" element at 0s expected: 300 but saw: 600 PASS - "left" property for "square2" element at 0s saw something close to: 0 -PASS - "left" property for "square1" element at 0.5s saw something close to: 450 +FAIL - "left" property for "square1" element at 0.5s expected: 450 but saw: 600 PASS - "left" property for "square2" element at 0.5s saw something close to: 150 -PASS - "-webkit-transform.4" property for "square3" element at 0s saw something close to: 300 +FAIL - "-webkit-transform.4" property for "square3" element at 0s expected: 300 but saw: matrix(1, 0, 0, 1, 600, 0) PASS - "-webkit-transform.4" property for "square4" element at 0s saw something close to: 0 -PASS - "-webkit-transform.4" property for "square3" element at 0.5s saw something close to: 450 +FAIL - "-webkit-transform.4" property for "square3" element at 0.5s expected: 450 but saw: matrix(1, 0, 0, 1, 600, 0) PASS - "-webkit-transform.4" property for "square4" element at 0.5s saw something close to: 150

I skipped them to paint the bot green - r132921. Please unskip them with the proper fix.

I don't understand how could that patch broke the text output of this patch. IMO the change are only take effect on the rendered output. From the JS perspective it could not make a change because the js bindings compute the animated values on the original Animation object from which we create a deep copy (and we don't even compute the values ahead of time in the web process). Noam, is that right? Locally I see this test as flaky. Ossy, is it possible that it was just always flaky?

I analyzed further and it seems like the reasons why it is flaky are way beyond coordinated graphics, the animations are not even exists in webcore when it fails. I tried to force layout, testRunner.display(), neither helps. Anyway I am going to mark them as flaky so we can at least run them and check pixel results.

Marked as flaky: http://trac.webkit.org/changeset/135171

(In reply to comment #4) > I analyzed further and it seems like the reasons why it is flaky are way beyond coordinated graphics, the animations are not even exists in webcore when it fails. I tried to force layout, testRunner.display(), neither helps. Anyway I am going to mark them as flaky so we can at least run them and check pixel results. Marking a test flakey means all results are accepted except crash. So pixel test failures aren't reported, only crash.

(In reply to comment #6) > (In reply to comment #4) > > I analyzed further and it seems like the reasons why it is flaky are way beyond coordinated graphics, the animations are not even exists in webcore when it fails. I tried to force layout, testRunner.display(), neither helps. Anyway I am going to mark them as flaky so we can at least run them and check pixel results. > > Marking a test flakey means all results are accepted except crash. > So pixel test failures aren't reported, only crash. You can mark it as "text flaky" with [ PASS TEXT ] which does not include accepting IMAGE fail.

Good point. :)