Bug 92100 – [Gtk] accessibility/canvas-accessibilitynodeobject.html is failing

• Status: NEW
• Component: WebKitGTK

[Zan Dobersek]

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

[Mario Sanchez Prada]

Adding Dominic to CC, just in case he could help us figure out the problem here.

[Dominic Mazzoni]

Thanks. I'll take a look, I might know what could cause this.

[Dominic Mazzoni]

Created attachment 154141 [details]
Patch

[Dominic Mazzoni]

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]

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]

> 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.