92100 2012-07-24 04:46:38 -0700 [Gtk] accessibility/canvas-accessibilitynodeobject.html is failing 2017-03-11 10:49:31 -0800 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) Unspecified Unspecified NEW Gtk, LayoutTestFailure P2 Normal --- 98347 1 zan dmazzoni bugs-noreply dmazzoni jdiggs mario oldest_to_newest 676661 0 zan 2012-07-24 04:46:38 -0700 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 676770 1 mario 2012-07-24 06:54:20 -0700 Adding Dominic to CC, just in case he could help us figure out the problem here. 676806 2 dmazzoni 2012-07-24 07:45:56 -0700 Thanks. I'll take a look, I might know what could cause this. 677200 3 154141 dmazzoni 2012-07-24 14:20:00 -0700 Created attachment 154141 Patch 677201 4 dmazzoni 2012-07-24 14:20:21 -0700 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. 677800 5 mario 2012-07-25 01:58:54 -0700 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. 678959 6 dmazzoni 2012-07-26 00:38:35 -0700 > 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. 154141 2012-07-24 14:20:00 -0700 2012-07-24 14:20:00 -0700 Patch bug-92100-20120724141951.patch text/plain 1636 dmazzoni SW5kZXg6IExheW91dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9D aGFuZ2VMb2cJKHJldmlzaW9uIDEyMzUyNikKKysrIExheW91dFRlc3RzL0NoYW5nZUxvZwkod29y a2luZyBjb3B5KQpAQCAtMSwzICsxLDE0IEBACisyMDEyLTA3LTI0ICBEb21pbmljIE1henpvbmkg IDxkbWF6em9uaUBnb29nbGUuY29tPgorCisgICAgICAgIFtHdGtdIGFjY2Vzc2liaWxpdHkvY2Fu dmFzLWFjY2Vzc2liaWxpdHlub2Rlb2JqZWN0Lmh0bWwgaXMgZmFpbGluZworICAgICAgICBodHRw czovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9OTIxMDAKKworICAgICAgICBSZXZp ZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBBZGRpdGlvbmFsIGluZm9ybWF0aW9u IG9mIHRoZSBjaGFuZ2Ugc3VjaCBhcyBhcHByb2FjaCwgcmF0aW9uYWxlLiBQbGVhc2UgYWRkIHBl ci1mdW5jdGlvbiBkZXNjcmlwdGlvbnMgYmVsb3cgKE9PUFMhKS4KKworICAgICAgICAqIGFjY2Vz c2liaWxpdHkvY2FudmFzLWFjY2Vzc2liaWxpdHlub2Rlb2JqZWN0Lmh0bWw6CisKIDIwMTItMDct MjQgIEp1bGllbiBDaGFmZnJhaXggIDxqY2hhZmZyYWl4QHdlYmtpdC5vcmc+CiAKICAgICAgICAg Q3Jhc2ggaW4gUmVuZGVyVGFibGVTZWN0aW9uOjpsYXlvdXRSb3dzCkluZGV4OiBMYXlvdXRUZXN0 cy9hY2Nlc3NpYmlsaXR5L2NhbnZhcy1hY2Nlc3NpYmlsaXR5bm9kZW9iamVjdC5odG1sCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIExheW91dFRlc3RzL2FjY2Vzc2liaWxpdHkvY2FudmFzLWFjY2Vzc2liaWxpdHlu b2Rlb2JqZWN0Lmh0bWwJKHJldmlzaW9uIDEyMzQyOSkKKysrIExheW91dFRlc3RzL2FjY2Vzc2li aWxpdHkvY2FudmFzLWFjY2Vzc2liaWxpdHlub2Rlb2JqZWN0Lmh0bWwJKHdvcmtpbmcgY29weSkK QEAgLTM3LDggKzM3LDExIEBAIGlmICh3aW5kb3cubGF5b3V0VGVzdENvbnRyb2xsZXIgJiYgd2lu ZG8KICAgICBmdW5jdGlvbiBhcHBlbmRGb2N1c2FibGVEZXNjZW5kYW50cyhheE9iamVjdCwgYXhG b2N1c2FibGVMaXN0KSB7CiAgICAgICAgIGZvciAodmFyIGkgPSAwOyBpIDwgYXhPYmplY3QuY2hp bGRyZW5Db3VudDsgaSsrKSB7CiAgICAgICAgICAgICB2YXIgYXhDaGlsZCA9IGF4T2JqZWN0LmNo aWxkQXRJbmRleChpKTsKLSAgICAgICAgICAgIGlmIChheENoaWxkLmlzRm9jdXNhYmxlKQorICAg ICAgICAgICAgaWYgKGF4Q2hpbGQuaXNGb2N1c2FibGUgJiYKKyAgICAgICAgICAgICAgICAoYXhD aGlsZC5yb2xlLnRvTG93ZXJDYXNlKCkuaW5kZXhPZigndGV4dCcpID09IC0xIHx8CisgICAgICAg ICAgICAgICAgIGF4Q2hpbGQucm9sZS50b0xvd2VyQ2FzZSgpLmluZGV4T2YoJ2ZpZWxkJykgPj0g MCkpIHsKICAgICAgICAgICAgICAgICBheEZvY3VzYWJsZUxpc3QucHVzaChheENoaWxkKTsKKyAg ICAgICAgICAgIH0KICAgICAgICAgICAgIGFwcGVuZEZvY3VzYWJsZURlc2NlbmRhbnRzKGF4Q2hp bGQsIGF4Rm9jdXNhYmxlTGlzdCk7CiAgICAgICAgIH0KICAgICB9Cg==