An AtkTable, in which the table does not manage its descendants, has a simple hierarchy, namely something like: -> table -> table cell -> table cell -> table cell -> table cell -> table cell The above hierarchy might represent: * a single column with five rows * a single row with five columns * two rows and three columns in which one cell spans two rows * etc., etc., etc. (Headers and captions can also be in the hierarchy, but they at the same level as the cells.) The remaining details about the table are not exposed through hierarchical structure, but rather through the AtkTable interface (the bulk of which was implemented in bug 25534). The accessible hierarchy of tables exposed to ATs by WebKitGtk is quite different: The table cells appear to each be represented by two children within the table rather than one. First they appear in row order as children of objects of ROLE_LIST_ITEM. Then they appear again in column order as children of objects of ROLE_UNKNOWN. While ATs providing access to Gtk+ apps do have to largely rely upon querying the table interface, they also have a need -- and an expectation -- to be able to access the table's hierarchy. The current implementation is too different (broken?) for this to be reliable.
Created attachment 49704 [details] proposed fix - includes layout test It turns out that the fix for bug 35418 also unborked the accessible table hierarchy somewhat. This patch seems to finish the job.
Drat! There are still other cases of borked tables. The previous patch changes are necessary, but additional changes will be as well. (I knew it seemed too easy....) :-(
Created attachment 49730 [details] rest of the fix - includes additional layout test The other issue turned out to be that any table identified as an AccessibilityTable always added a bunch of children without considering whether or not those children should be "ignored" by the platform. This patch changes that so an AccessibilityTable only adds children that are not "ignored." It also makes corresponding Gtk-specific changes so that we can actually specify that they should be ignored. Note that this patch assumes/depends upon the previous one. Therefore, I'm not yet flagging it for review as the bots will just spit up on it. But as far as I'm concerned at the moment, this is everything that needs to be done w.r.t. this bug pending code review.
Comment on attachment 49704 [details] proposed fix - includes layout test OK.
Is the second patch supposed to be marked for review?
Comment on attachment 49730 [details] rest of the fix - includes additional layout test I assume the bots will spit up on this one (seeing as how the first one is still in the commit queue and this patch assumes the first). But having said that, a review would be lovely. Thanks for asking, Eric.
Comment on attachment 49704 [details] proposed fix - includes layout test Clearing flags on attachment: 49704 Committed r55623: <http://trac.webkit.org/changeset/55623>
Comment on attachment 49730 [details] rest of the fix - includes additional layout test Looks good to me.
Comment on attachment 49730 [details] rest of the fix - includes additional layout test Clearing flags on attachment: 49730 Committed r55680: <http://trac.webkit.org/changeset/55680>
All reviewed patches have been landed. Closing bug.