Bug 92100

Summary: [Gtk] accessibility/canvas-accessibilitynodeobject.html is failing
Product: WebKit Reporter: Zan Dobersek <zan>
Component: WebKitGTKAssignee: Dominic Mazzoni <dmazzoni>
Status: NEW    
Severity: Normal CC: bugs-noreply, dmazzoni, jdiggs, mario
Priority: P2 Keywords: Gtk, LayoutTestFailure
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 98347    
Attachments:
Description Flags
Patch none

Zan Dobersek
Reported 2012-07-24 04:46:38 PDT
The test fails since it has been (re)introduced in r123428[1]. Here's the diff from the 64-bit debug builder (but the test fails on all the other builders as well): --- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/accessibility/canvas-accessibilitynodeobject-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/accessibility/canvas-accessibilitynodeobject-actual.txt @@ -4,16 +4,16 @@ On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". -PASS axRenderObjects.length is axNodeObjects.length -PASS i == 0; axRenderObject.role == axNodeObject.role is true -PASS i == 1; axRenderObject.role == axNodeObject.role is true -PASS i == 2; axRenderObject.role == axNodeObject.role is true -PASS i == 3; axRenderObject.role == axNodeObject.role is true -PASS i == 4; axRenderObject.role == axNodeObject.role is true -PASS i == 5; axRenderObject.role == axNodeObject.role is true -PASS i == 6; axRenderObject.role == axNodeObject.role is true -PASS i == 7; axRenderObject.role == axNodeObject.role is true -PASS i == 8; axRenderObject.role == axNodeObject.role is true +FAIL axRenderObjects.length should be 25. Was 9. +FAIL i == 0; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 1; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 2; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 3; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 4; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 5; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 6; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 7; axRenderObject.role == axNodeObject.role should be true. Was false. +FAIL i == 8; axRenderObject.role == axNodeObject.role should be true. Was false. PASS successfullyParsed is true TEST COMPLETE [1] - http://trac.webkit.org/changeset/123428
Attachments
Patch (1.60 KB, patch)
2012-07-24 14:20 PDT, Dominic Mazzoni 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mario Sanchez Prada
Comment 1 2012-07-24 06:54:20 PDT
Adding Dominic to CC, just in case he could help us figure out the problem here.
Dominic Mazzoni
Comment 2 2012-07-24 07:45:56 PDT
Thanks. I'll take a look, I might know what could cause this.
Dominic Mazzoni
Comment 3 2012-07-24 14:20:00 PDT
Created attachment 154141 [details] Patch
Dominic Mazzoni
Comment 4 2012-07-24 14:20:21 PDT
OK, I see what's going on. In the second half of the test, it recursively explores all descendants of the canvas. It tries to distinguish between links and controls and other nodes based on whether they're focusable or not. But in the GTK port, all text nodes are reported as focusable according to ATK. I think that's because of how Orca uses caret browsing to move throughout the page, right? This patch is a bit of a hack - I don't have a GTK build, could someone try it and see if it fixes the issue, and send me a diff otherwise? I will definitely do a cleaner fix after I've implemented more of AccessibilityNodeObject.
Mario Sanchez Prada
Comment 5 2012-07-25 01:58:54 PDT
Thanks Dominic for the prompt reply. (In reply to comment #4) > OK, I see what's going on. > > In the second half of the test, it recursively explores all descendants of > the canvas. It tries to distinguish between links and controls and other > nodes based on whether they're focusable or not. > > But in the GTK port, all text nodes are reported as focusable according to > ATK. I think that's because of how Orca uses caret browsing to move throughout > the page, right? Yeah, exactly. > This patch is a bit of a hack - I don't have a GTK build, could someone try > it and see if it fixes the issue, and send me a diff otherwise? The patch works here too, but I think we are hiding a bigger bug by writing the Layout test like that. As I can see in Accerciser, without the patch applied, for the first list (axRenderObjects) everything seems to be normal in the a11y hierarchy: section (not in the list, role of the parent AX object) link push button entry check box radio button push button combo box menu menu item menu item push button link However, for the second list (axNodeObjects), I see this: image (not in the list, role of the parent AX object) text link text push button text entry text check box text radio button text push button text combo box text text text push button text link text Even the subtree under combo box seems to be wrong in that case! So, assuming the hierarchies should be identical (shouldn't they?) in those two cases, I guess the main issue we are seeing here is that the AX hierarchy is not being properly generated in the second case, not sure if that's because of having an AXObject of role 'image' as the root for the subtree, if that's because of the associated HTML node being a <canvas> or because of something else. What do you think? Does that make sense? > I will definitely do a cleaner fix after I've implemented more of AccessibilityNodeObject. I think the most sane thing here, in order not to hide a bigger bug if it's there, would be to keep this bug open with the test in TestExpectations as it is now and file a new bug for this issue with the a11y trees, if we agree that's the problem behind all this. But prior to filing that new bug, I would like to hear what do you think about all this.
Dominic Mazzoni
Comment 6 2012-07-26 00:38:35 PDT
> So, assuming the hierarchies should be identical (shouldn't they?) in those two cases, I guess the main issue we are seeing here is that the AX hierarchy is not being properly generated in the second case, not sure if that's because of having an AXObject of role 'image' as the root for the subtree, if that's because of the associated HTML node being a <canvas> or because of something else. Yes, this is not surprising. I just checked in a change that makes it possible for nodes in a canvas subtree to be accessible. These nodes do not have renderers, so I created a new class, AccessibilityNodeObject. This is still incomplete, I've only implemented a few of the methods - over time I'll try to migrate as much as possible from AccessibilityRenderObject to AccessibilityNodeObject. However, even when it's done, there will be some minor differences between the ax tree generated from Nodes and the ax tree generated from RenderObjects. I doubt it will matter; the only purpose is to create accessible fallback content for widgets built using canvas. It's possible that AccessibilityNodeObject isn't handling whitespace the same way? Either way, I'll look into it. > I think the most sane thing here, in order not to hide a bigger bug if it's there, would be to keep this bug open with the test in TestExpectations as it is now and file a new bug for this issue with the a11y trees, if we agree that's the problem behind all this. Sounds good.
Note You need to log in before you can comment on or make changes to this bug.