[Webkit-unassigned] [Bug 132134] [GTK] TestWebKitAccessibility unit test is flaky.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 25 01:24:57 PDT 2014


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





--- Comment #4 from Mario Sanchez Prada <mario at webkit.org>  2014-04-25 01:25:17 PST ---
(In reply to comment #3)
> I wonder why we have a unit test for accessibility since we don't expose any API for accessibility. Shouldn't it be tested with layout tests instead?

Accessibility is a tricky beast :)

You are right in what that WebKit2GTK+ does not expose explicitly any API related to accessibility as in other APIs exposed in the UIProcess (in UIProcess/API/gtk). 

But that does not mean there is no API exposed at all. What happens here is that most of the accessibility is exposed directly from WebCore, by implementing different ATK interfaces (there you have the exposed API). This, in WebKit2, means that the accessibility ATK-based API is actually exposed to the world right from the WebProcess, not the UI Process.

However, there's still something we need to do from the UIProcess related to WebKit2, so ATs can see the whole ATK hierarchy exposed in the Web Process as "connected" to the very tiny ATK hierarchy present in the UIProcess (basically, an  AtkObject associated to the WebView widget):

We need to connect both hierarchies using AtkSocket and AtkPlug so ATs, which "speak" AT-SPI only -not ATK-, they will see everything as a single hierarchy, starting up at the level of the AtkObject for the WebView and going all the way down into the domain of WebProcess, where the "real accessibility stuff" lives.

So, this is what this TestWebKitAccessibility unit test checks: that such a connection between those two worlds is not broken. That's precisely why it uses AT-SPI instead of ATK to navigate top - down, so it can check that it can find the relevant AT-SPI objects wrapping ATK objects both in the UI Process and the Web Process.

Layout tests are not enough to test this because WebKitTestRunner uses the InjectedBundle to get "direct access" to the WebProcess for testing purposes. So, having an accessibility layout test passing using WKTR does not guarantee that this connection using AtkSocket/AtkPlug is not broken.

You can check this post of mine from last year where I tried to explain the whole thing all together, since it can be quite confusing: http://mariospr.org/2013/02/03/accessibility-in-webkitgtk/

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



More information about the webkit-unassigned mailing list