Bug 71665

Summary: [GTK] platform/gtk/accessibility/name-from-label.html fails
Product: WebKit Reporter: Philippe Normand <pnormand>
Component: WebKitGTKAssignee: Mario Sanchez Prada <mario>
Status: RESOLVED FIXED    
Severity: Normal CC: mario, pnormand, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch pnormand: review+

Philippe Normand
Reported 2011-11-07 04:39:27 PST
Currently skipped in GTK as anonymous flaky but failure looks consistent here: --- /home/phil/gst/jhbuild/build/WebKit/WebKitBuild/Release/layout-test-results/platform/gtk/accessibility/name-from-label-expected.txt +++ /home/phil/gst/jhbuild/build/WebKit/WebKitBuild/Release/layout-test-results/platform/gtk/accessibility/name-from-label-actual.txt @@ -4,8 +4,8 @@ On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". -PASS child.role is 'AXRole: entry' -PASS child.title is 'AXTitle: Full Name:' +FAIL child.role should be AXRole: entry. Was AXRole: paragraph. +FAIL child.title should be AXTitle: Full Name:. Was AXTitle: . PASS successfullyParsed is true TEST COMPLETE
Attachments
Patch (2.64 KB, patch)
2011-11-21 06:15 PST, Mario Sanchez Prada 		pnormand: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mario Sanchez Prada
Comment 1 2011-11-21 06:15:31 PST
Created attachment 116073 [details] Patch
Mario Sanchez Prada
Comment 2 2011-11-21 06:19:51 PST
(In reply to comment #1) > Created an attachment (id=116073) [details] > Patch It seems this has been a problem even before November the 7th (tried with a commit from Nov 1st, and was failing as well there). I have been trying to find out the exact point where it start failing but couldn't find it. However, as per visual inspection in the code, I now wonder how it could be working fine before, since its obvious that the form object in the middle was not being taking into account when it should, so either form objects were explicitly not being exposed before (which is not the case I think) or there was a bug somewhere else (e.g. determining when the webArea is focusable, determining if a form is visible or not...) that was fixed at some point recently, unleashing the problem with this wrongly implemented layout test (that I wrote btw, so assuming my fault on that :(). My guessing is that the reason why it started failing recently was the later one (a bug somewhere else that got fixed, unveiling the problem with this test), so that's why I propose now this patch, which is basically a rewrite of the layout test that properly considers the a11y hierarchy.
Philippe Normand
Comment 3 2011-11-21 06:23:00 PST
It was skipped *before* I opened this bug, which I did when I moved the flaky tests in tests_expectations.txt
Philippe Normand
Comment 4 2011-11-21 07:15:53 PST
Comment on attachment 116073 [details] Patch Looks sane to me!
Mario Sanchez Prada
Comment 5 2011-11-22 00:30:57 PST
Committed r100979: <http://trac.webkit.org/changeset/100979>
Note You need to log in before you can comment on or make changes to this bug.