100769 2012-10-30 10:05:21 -0700 [Qt][WK2] REGRESSION(r132907): It made animations/negative-delay.html flaky 2014-02-01 19:00:44 -0800 1 1 1 Unclassified WebKit New Bugs 420+ All All RESOLVED INVALID Qt, QtTriaged P2 Normal --- 79666 100673 1 ossy webkit-unassigned kbalazs kenneth noam ossy oldest_to_newest 754465 0 ossy 2012-10-30 10:05:21 -0700 --- /home/webkitbuildbot/slaves/release64bitWebKit2_EC2/buildslave/qt-linux-64-release-webkit2/build/layout-test-results/animations/negative-delay-expected.txt +++ /home/webkitbuildbot/slaves/release64bitWebKit2_EC2/buildslave/qt-linux-64-release-webkit2/build/layout-test-results/animations/negative-delay-actual.txt @@ -1,9 +1,9 @@ -PASS - "left" property for "square1" element at 0s saw something close to: 300 +FAIL - animation "square-move" is not running 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 - animation "square-move" is not running PASS - "left" property for "square2" element at 0.5s saw something close to: 150 -PASS - "webkitTransform.4" property for "square3" element at 0s saw something close to: 300 +FAIL - animation "square-translate" is not running PASS - "webkitTransform.4" property for "square4" element at 0s saw something close to: 0 -PASS - "webkitTransform.4" property for "square3" element at 0.5s saw something close to: 450 +FAIL - animation "square-translate" is not running PASS - "webkitTransform.4" property for "square4" element at 0.5s saw something close to: 150 754466 1 ossy 2012-10-30 10:05:49 -0700 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 754478 2 ossy 2012-10-30 10:16:56 -0700 I skipped them to paint the bot green - r132921. Please unskip them with the proper fix. 768122 3 kbalazs 2012-11-15 08:43:27 -0800 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? 770829 4 kbalazs 2012-11-19 09:53:47 -0800 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. 770832 5 kbalazs 2012-11-19 09:59:48 -0800 Marked as flaky: http://trac.webkit.org/changeset/135171 772802 6 ossy 2012-11-21 04:44:01 -0800 (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. 772866 7 kbalazs 2012-11-21 06:16:42 -0800 (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. 772916 8 ossy 2012-11-21 06:55:08 -0800 Good point. :)