Bug 111004

Summary: Layout Test accessibility/svg-remote-element.html is flaky
Product: WebKit Reporter: Eric Seidel (no email) <eric>
Component: Tools / TestsAssignee: Philip Rogers <pdr>
Status: NEW    
Severity: Normal CC: cfleizach, dmazzoni, pdr, toyoshim, vsevik
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Eric Seidel (no email)
Reported 2013-02-27 12:59:50 PST
The following layout test is flaky on linux/win accessibility/svg-remote-element.html --- /src/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/accessibility/svg-remote-element-expected.txt +++ /src/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/accessibility/svg-remote-element-actual.txt @@ -4,29 +4,29 @@ On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". -container location: (7, 7) +container location: (7, 7.5) Face role: AXRole: AXButton Face label: AXDescription: face FaceX: 0 -FaceY: 0 +FaceY: 0.5 Eye role: AXRole: AXButton Eye label: AXDescription: left-eye EyeX: 103 -EyeY: 148 +EyeY: 147.5 Nose role: AXRole: AXButton Nose label: AXDescription: nose NoseX: 193 -NoseY: 206 +NoseY: 205.5 Mouth role: AXRole: AXButton Mouth label: AXDescription: smile MouthX: 115 -MouthY: 275 +MouthY: 274 PASS successfullyParsed is true
Attachments
chris fleizach
Comment 3 2013-02-27 13:59:24 PST
maybe making the the positions be within some sort of tolerance, like shouldBeTrue(face.X > 200 && face.X < 205) would reduce this flakiness.
Dominic Mazzoni
Comment 4 2013-02-27 15:06:02 PST
To clarify, do you mean "flaky" as in sometimes succeeding and sometimes failing, or is it giving slightly different expectations on different platforms? If it really is returning slightly different results on the same platform sometimes, what's the underlying cause?
Eric Seidel (no email)
Comment 5 2013-02-27 15:08:22 PST
The bots are seeing it sometimes return one result and sometimes another on both linux and win. See the test-results link in comment 1.
Eric Seidel (no email)
Comment 6 2013-02-27 15:09:15 PST
The diff in comment 0 is from running the test locally on my linux machine with run-webkit-tests --chromium --iterations=100 accessibility/svg-remote-element.html
chris fleizach
Comment 7 2013-02-27 15:17:54 PST
(In reply to comment #6) > The diff in comment 0 is from running the test locally on my linux machine with run-webkit-tests --chromium --iterations=100 accessibility/svg-remote-element.html Following up to Dominics comment, I agree this is probably exposing an more fundamental problem with the layout of SVG remote items or with the values it reports. It's unlikely that the actual cause is accessibility. However, I'm not opposed to making the test more tolerant, given that the differences are so small
Dominic Mazzoni
Comment 8 2013-02-27 15:29:22 PST
pdr@ graciously volunteered to take a look and see if the bug is in SVG. In the meantime, let's not mask the problem by adding tolerance...at least until we understand it better. I'd rather mark the test as flaky in TestExpectations.
Philip Rogers
Comment 9 2013-02-27 17:14:23 PST
(In reply to comment #8) > pdr@ graciously volunteered to take a look and see if the bug is in SVG. > > In the meantime, let's not mask the problem by adding tolerance...at least until we understand it better. > > I'd rather mark the test as flaky in TestExpectations. Small update: running with --run-singly does not expose the flakiness, so I think this is likely a state issue between tests. The test fails due to differences in the following values: container.clickPointY, container.clickPointX, container.height and container.width. Good: clickPointX=208, clickPointY=208, width=400, height=400 Bad: clickPointX=56, clickPointY=18, width=96, height=19 I don't see a logical source for these values other than accessibilityController containing stale state.
Philip Rogers
Comment 10 2013-03-05 19:46:21 PST
*** Bug 111062 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.