Headings not longer have an AXTitle if they have a link as the only child rdar://14699680
Created attachment 208562 [details] patch
<rdar://problem/14699680>
Comment on attachment 208562 [details] patch This doesn’t look right. The mode has 3 bits but they don’t seem to be three independent switches.
Created attachment 208656 [details] patch
Comment on attachment 208656 [details] patch Attachment 208656 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/1455498
Created attachment 208664 [details] patch
Comment on attachment 208664 [details] patch Attachment 208664 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/1446757
Created attachment 208665 [details] patch
Comment on attachment 208665 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=208665&action=review This is not an issue only on the Mac, but apparently affecting also the GTK/EFL ports, so thanks for fixing this. I just have a concern about the layout test, which I'm not sure whether it might be flaky in some case. See my comment below... > LayoutTests/accessibility/heading-title-includes-links.html:24 > +<script> > + > + description("This tests that the title of a heading will include links if available."); > + > + if (window.accessibilityController) { > + > + debug("Heading title: " + accessibilityController.accessibleElementById("heading").title); > + } I found that this test misbehaves in the GTK+ port, as if it was "too soon" to ask for the title of this heading at this moment, as I could check that the visible text (which is what accessibleTitle() ends up calling in this case) is not available at this moment, causing it to return an empty string. However, I also checked that delaying the whole thing for a further iteration of the main loop works fine for the GTK platform, which then is able to print "Apple" for the heading element: <html> <head> <script src="../fast/js/resources/js-test-pre.js"></script> </head> <body id="body"> <h1 id="heading"> <a href="Apple.com"> Apple </a> </h1> <p id="description"></p> <div id="console"></div> <script> description("This tests that the title of a heading will include links if available."); function runTestsOnIdle() { debug("Heading title: " + accessibilityController.accessibleElementById("heading").title); window.testRunner.notifyDone(); } if (window.testRunner && window.accessibilityController) { window.testRunner.dumpAsText(); window.testRunner.waitUntilDone(); } // Do this on idle, so we make sure the visible text will be available. window.setTimeout('runTestsOnIdle()', 0) </script> <script src="../fast/js/resources/js-test-post.js"></script> </body> </html> One problem with this test is that it will print the "Heading title: AXTitle: Apple" line after the "TEST COMPLETE". However, I'm not quite sure whether this is unveiling an issue specific to the GTK+ port (which should perhaps work fine in the original test) or whether the test might be inherently flaky and should be rewritten in a way similar to the proposed one. What do you think?
(In reply to comment #9) > (From update of attachment 208665 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=208665&action=review > > This is not an issue only on the Mac, but apparently affecting also the GTK/EFL ports, so thanks for fixing this. > > I just have a concern about the layout test, which I'm not sure whether it might be flaky in some case. See my comment below... > > > LayoutTests/accessibility/heading-title-includes-links.html:24 > > +<script> > > + > > + description("This tests that the title of a heading will include links if available."); > > + > > + if (window.accessibilityController) { > > + > > + debug("Heading title: " + accessibilityController.accessibleElementById("heading").title); > > + } > > I found that this test misbehaves in the GTK+ port, as if it was "too soon" to ask for the title of this heading at this moment, as I could check that the visible text (which is what accessibleTitle() ends up calling in this case) is not available at this moment, causing it to return an empty string. > > However, I also checked that delaying the whole thing for a further iteration of the main loop works fine for the GTK platform, which then is able to print "Apple" for the heading element: > > <html> > <head> > <script src="../fast/js/resources/js-test-pre.js"></script> > </head> > <body id="body"> > > <h1 id="heading"> > <a href="Apple.com"> > Apple > </a> > </h1> > > <p id="description"></p> > <div id="console"></div> > > <script> > description("This tests that the title of a heading will include links if available."); > function runTestsOnIdle() > { > debug("Heading title: " + accessibilityController.accessibleElementById("heading").title); > window.testRunner.notifyDone(); > } > > if (window.testRunner && window.accessibilityController) { > window.testRunner.dumpAsText(); > window.testRunner.waitUntilDone(); > } > > // Do this on idle, so we make sure the visible text will be available. > window.setTimeout('runTestsOnIdle()', 0) > </script> > <script src="../fast/js/resources/js-test-post.js"></script> > </body> > </html> > > > One problem with this test is that it will print the "Heading title: AXTitle: Apple" line after the "TEST COMPLETE". However, I'm not quite sure whether this is unveiling an issue specific to the GTK+ port (which should perhaps work fine in the original test) or whether the test might be inherently flaky and should be rewritten in a way similar to the proposed one. > > What do you think? I'm OK changing the patch so that we don't get a failure, but I think GTK should look into this. There's no good reason I can think of that this shouldn't work
http://trac.webkit.org/changeset/154058
(In reply to comment #10) > [...] > I'm OK changing the patch so that we don't get a failure, but I think GTK > should look into this. There's no good reason I can think of that this > shouldn't work Thanks for considering my comments. I will update expectations for this tests in GTK and will try to investigate why this weird behaviour is happening in GTK.