[Webkit-unassigned] [Bug 118359] [ATK] Do not expose '\n' for wrapped lines with ATK_TEXT_BOUNDARY_CHAR

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 3 10:26:39 PDT 2013


--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com>  2013-07-03 10:28:37 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > (From update of attachment 206007 [details] [details])
> > Can this be tested in WebKit2? I'm not sure it's worth it adding new unit tests > for wk1 API.
> We can not test this in WebKit1 because we are checking the implementation of ATK interfaces here, and we only can use ATK APIs if we are in the same process where the accessibility hierarchy lives.
> What we can do in WebKit2, though, is to check the accessibility hierarchy (and indirectly the ATK implementation) through AT-SPI2, but then you introduce several points of failure more, such as AT-SPI2, the registry, D-Bus and the ATK bridge. And on top of that you would not be testing the ATK implementation either.
> So, that's why, at the moment, in WebKit2 we use AT-SPI2 to check only the "connection" between the two process by terms of AtkSocket/AtkPlug, and we leave the actual checking of the ATK implementation to the unit tests in WebKit1.
> Additionally, these specific tests wouldn't work either in WebKit2 even if we implemented them in terms of AT-SPI2, since the LINE boundary will be completely broken there while we keep using Pango/Gail for that (see bugs 73433 and 114867).
> However, I agree that we should think of a solution for the future at some point, maybe by migrating all the ATK-specific tests to AT-SPI2 specific ones. But for the time being it would be great if we could keep using this testatk.c file.
> At least until we manage to get rid of the Pango/Gail dependency, which is the other reason why WebKit2 is not fully accessible right now.

Ok, we'll port it then when we add support for tests in the web process using injected bundle.

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