Bug 100769
| Summary: | [Qt][WK2] REGRESSION(r132907): It made animations/negative-delay.html flaky | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | kbalazs, kenneth, noam, ossy |
| Priority: | P2 | Keywords: | Qt, QtTriaged |
| Version: | 420+ | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 79666, 100673 | ||
Csaba Osztrogonác
--- /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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Csaba Osztrogonác
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
Csaba Osztrogonác
I skipped them to paint the bot green - r132921.
Please unskip them with the proper fix.
Balazs Kelemen
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?
Balazs Kelemen
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.
Balazs Kelemen
Marked as flaky: http://trac.webkit.org/changeset/135171
Csaba Osztrogonác
(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.
Balazs Kelemen
(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.
Csaba Osztrogonác
Good point. :)