[Webkit-unassigned] [Bug 123153] New: [ATK] Avoid explicit traversal of text controls and the render tree in AtkText implementation

Tue Oct 22 05:43:42 PDT 2013

https://bugs.webkit.org/show_bug.cgi?id=123153

           Summary: [ATK] Avoid explicit traversal of text controls and
                    the render tree in AtkText implementation
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Accessibility
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mario at webkit.org
                CC: jdiggs at igalia.com, apinheiro at igalia.com,
                    k.czech at samsung.com,
                    webkit-bug-importer at group.apple.com

At the moment, the implementation of atk_text_get_text() relies sometimes on code that do things such as manually traversing the render tree, or manually checking line by line for text controls, to compose the text for a given AtkObject. Fortunately, this is only done when certain conditions apply, such as exposing an anonymous block or multiline text controls, but to me is an error-prone approach and most likely not the way to go, since by doing things like this we are not properly considering all the possible scenarios that might happen when traversing text, which is a task better suited for the TextIterator, for instance.

Another reason why that code is placed there (and the textForRenderer() function specially) is to deal with the case of exposing replaced objects to AT-SPI/ATK ATs, which again is something that the TextIterator should probably do instead, IMHO.

Furthermore, after some conversations with Joanie on IRC, I learned that the way we are currently exposing those replaced objects is not the right one, even if some test expectations seem to say so. For instance, consider the following code:

  <html><body><p>This is a text with a <button type="button">nice button</button> in the middle</p></body></html>

At the moment, the code that we have in WebKitGTK+ exposes the text for that paragraph as this:

   "This is a text with a <obj>nice button in the middle"

...and this is coherent with what the test expectations for layout tests checking the exposure of replaced objects claim to expect (e.g. deleting-iframe-destroys-axcache). However, the expected output for Orca would better be something like this:

   "This is a text with a <obj> in the middle"  --> Orca can query on that <obj> to know what's in, if she wants

So, this means that the current code, besides being error-prone, is wrong anyway. Great :)

Fortunately, after doing some experiments locally, I believe there's a better way to do all this, and it is by removing all that code (textForObject() and textForRenderer() mainly) from WebKitAccessibleInterfaceText.cpp and make sure the same functionality is achieved by using the AccessibilityObject API (which we are already using anyway) + slightly modifying the TextIterator to allow it not walk the subtree under a replaced object when asked for it (presumably, only EFL and GTK will want that).

I plan to upload such a patch soon to this bug. Hope it will make WebKitGTK/EFL a11y support of AtkText better, without disturbing the Mac port at all.

Let's see...

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.