Bug 240517 – [GTK] AX: AtspiCollection is not implemented on the document

• Component: Accessibility
• Status: RESOLVED FIXED

[Joanmarie Diggs]

Steps to reproduce:
1. Launch Epiphany using WebKitGtk 2.36 (Gtk 3).
2. Launch Accerciser and examine the accessibility tree's implemented interfaces

Expected results: All objects in the accessibility tree claim to have implemented the collection interface

Actual results: All objects coming from Gtk in the accessibility tree claim to have implemented the collection interface. Any accessible which exposes "WebKitGTK" as the "toolkit" object attribute does not.

Impact: Orca's structural navigation commands (next/previous heading, next/previous form field, list of all headings, list of all form fields, etc., etc.) do not work. At the present time, there is silence (due to Orca not handling the unexpected not-implemented error). I'm fixing that in Orca, but that just causes Orca to announce that there are no headings, form fields, etc., etc.

Given that distros are shipping WebKitGtk 2.36, it would be EXTREMELY appreciated if this can be seen as a critical bug fix to be addressed in 2.36.x.

Note that the collection interface is NOT an ATK thing. It's done entirely in AT-SPI2 so applications and toolkits get it "for free." I'm hoping it will be possible to implement support in WebKitGtk by simply using the default implementation rather than having to do the work from scratch.

Also note that while an AT *could* expect to use the collection interface on any accessible element, Orca only queries it on the accessible document. So as long as it's implemented there, I *think* Orca should be fine.

See:
* https://gitlab.gnome.org/GNOME/at-spi2-atk/-/blob/master/atk-adaptor/adaptors/collection-adaptor.c
* https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/master/atspi/atspi-collection.c

[Radar WebKit Bug Importer]

<rdar://problem/93419230>

[Michael Catanzaro]

(In reply to Joanmarie Diggs from comment #0)
> Given that distros are shipping WebKitGtk 2.36, it would be EXTREMELY
> appreciated if this can be seen as a critical bug fix to be addressed in
> 2.36.x.

Hi Joanie! I understand this is not something you know how to easily fix? I'm afraid that with Carlos Garcia out for a little while, you're the only WebKitGTK a11y expert remaining.

Since this is critical, I think we could probably switch 2.36 back to the old implementation, if you recommend doing so. The code was not deleted until after we branched. Of course, fixing only 2.36 would leave 2.38+ broken, so the problem will hit distros again pretty soon, but it would at least buy us time until Carlos Garcia returns. Adrian is planning to do a 2.36.3 release next week, so we should decide quickly whether to do this huge revert or not. I'm certain Carlos would prefer that we investigate and fix things properly, but realistically, if we need it solved quick, switching back to ATK would be pragmatic.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #2)
> (In reply to Joanmarie Diggs from comment #0)
> > Given that distros are shipping WebKitGtk 2.36, it would be EXTREMELY
> > appreciated if this can be seen as a critical bug fix to be addressed in
> > 2.36.x.
> 
> Hi Joanie! I understand this is not something you know how to easily fix?
> I'm afraid that with Carlos Garcia out for a little while, you're the only
> WebKitGTK a11y expert remaining.
> 
> Since this is critical, I think we could probably switch 2.36 back to the
> old implementation, if you recommend doing so. The code was not deleted
> until after we branched. Of course, fixing only 2.36 would leave 2.38+
> broken, so the problem will hit distros again pretty soon, but it would at
> least buy us time until Carlos Garcia returns. Adrian is planning to do a
> 2.36.3 release next week, so we should decide quickly whether to do this
> huge revert or not. I'm certain Carlos would prefer that we investigate and
> fix things properly, but realistically, if we need it solved quick,
> switching back to ATK would be pragmatic.

I took a quick look at the GTK4 sources, and I do not see an implementation
of the Collection interface there. The new ATSPI implementation in WebKit
loosely follows its structure, so I *suppose* that's the reason why the
Collection interface was not implemented yet.

I tried Accerciser on a few GTK4 applications (Text Editor, Extensions,
GNOME Setting, Amberol) and indeed I cannot see the Collection interface
being implemented anywhere. Does Orca work with GTK4 applications at all
in this regard? 

(Also please bear with me, I am far from being an expert in a11y, but at
least I understand some bits these days due to helping out with reviewing
the new ATSPI implementation in WebKit =])

[Michael Catanzaro]

Ah, interesting. Thanks for looking, Adrian!

[Joanmarie Diggs]

At the present time, Orca only uses AtspiCollection for web content. Thus what GTK4 itself does -- or fails to do -- is irrelevant unless it impacts what gets exposed via WebKitGtk.

Regarding switching back to ATK temporarily.... <insert shrug here> I've given the Orca users a heads up on the issue. And for web browsing, the reality is that Orca + Chromium and Gecko work better. (Something I hope to change in the not-to-distant future with all these fixes we're getting thanks to Carlos!)

I *think* that for things like email composition and reading in Evolution, things will be GoodEnough(tm) with the current state + some changes in Orca (which have and/or will be put into current stable and old stable).

[Carlos Garcia Campos]

Created attachment 460476 [details]
Patch

[Adrian Perez]

Comment on attachment 460476 [details]
Patch

Patch logic looks fine, but there are a couple of build issues introduced:

FAILED: bin/TestWebKitAPI/TestWebCore 
: && /usr/bin/c++ -fdiagnostics-color=always -Wextra -Wall -pipe -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wcast-align -Wno-tautological-compare  -fno-strict-aliasing -fno-exceptions -fno-rtti -O3 -DNDEBUG -fuse-ld=lld -Wl,--disable-new-dtags @CMakeFiles/TestWebCore.rsp -o bin/TestWebKitAPI/TestWebCore  && :
ld.lld: error: undefined symbol: WebCore::AccessibilityObjectAtspi::s_collectionFunctions
>>> referenced by UnifiedSource-aba958d6-5.cpp
>>>               Source/WebCore/CMakeFiles/WebCore.dir/./__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-aba958d6-5.cpp.o:(WebCore::AccessibilityObjectAtspi::registerObject() (.part.0))

and this:

In file included from /app/webkit/WebKitBuild/Release/WTF/Headers/wtf/Hasher.h:27,
                 from /app/webkit/Source/WebCore/platform/graphics/FloatPoint.h:31,
                 from /app/webkit/Source/WebCore/platform/graphics/FloatRect.h:29,
                 from /app/webkit/Source/WebCore/dom/ElementContext.h:29,
                 from /app/webkit/Source/WebCore/loader/FrameLoaderTypes.h:31,
                 from /app/webkit/Source/WebCore/loader/FrameLoaderClient.h:33,
                 from /app/webkit/Source/WebCore/accessibility/AccessibilityObjectInterface.h:30,
                 from /app/webkit/Source/WebCore/accessibility/AccessibilityObject.h:32,
                 from /app/webkit/Source/WebCore/accessibility/AccessibilityNodeObject.h:31,
                 from /app/webkit/Source/WebCore/accessibility/AccessibilityRenderObject.h:31,
                 from /app/webkit/Source/WebCore/accessibility/AccessibilityTree.h:32,
                 from /app/webkit/Source/WebCore/accessibility/AccessibilityTree.cpp:30,
                 from /app/webkit/WebKitBuild/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-aba958d6-5.cpp:1:
/app/webkit/WebKitBuild/Release/WTF/Headers/wtf/URL.h:327:13: note: candidate: ‘bool WTF::operator==(const WTF::URL&, const WTF::URL&)’
  327 | inline bool operator==(const URL& a, const URL& b)
      |             ^~~~~~~~
/app/webkit/WebKitBuild/Release/WTF/Headers/wtf/URL.h:327:35: note:   no known conversion for argument 1 from ‘const WTF::String’ to ‘const WTF::URL&’
  327 | inline bool operator==(const URL& a, const URL& b)
      |                        ~~~~~~~~~~~^
In file included from /app/webkit/WebKitBuild/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-aba958d6-5.cpp:7:
/app/webkit/Source/WebCore/accessibility/atspi/AccessibilityObjectCollectionAtspi.cpp:156:23: error: no match for ‘operator==’ (operand types are ‘const WTF::String’ and ‘const char [11]’)


There has been some commits lately removing a few implicit constructors and
conversions between URL and String. Maybe you'll want to setup a to clone from
the GitHub repository now that it's the canonical source of truth (pun intended :)

Also I assume we'll want this backported to the 2.36.x release branch, so I will
be listing it there tentativaly.

[Carlos Garcia Campos]

Yes, I wrote this patch on the 2.36 branch, that's why it fails in trunk. I'll fix the issues and submit a new patch.

[Carlos Garcia Campos]

Created attachment 460501 [details]
Patch

[Adrian Perez]

FWIW, I suppose the tag in the subject could be [ATSPI], but sometimes
we've been using [GTK] or [WPE] for things that affect both ports anyway
so I'm fine leaving it as-is 😉️

[EWS]

Committed 251906@main (9496bf12e02e): <https://commits.webkit.org/251906@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 460501 [details].