| Summary: | [GTK] AX: AtspiCollection is not implemented on the document | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Joanmarie Diggs <jdiggs> | ||||||
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Major | CC: | aboxhall, andresg_22, aperez, apinheiro, bugs-noreply, cfleizach, cgarcia, dmazzoni, ews-watchlist, jbicha, jcraig, mcatanzaro, samuel_white, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
|
Description
Joanmarie Diggs
2022-05-17 05:55:21 PDT
(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. (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 =]) Ah, interesting. Thanks for looking, Adrian! 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). Created attachment 460476 [details]
Patch
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. 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. Created attachment 460501 [details]
Patch
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 😉️ 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]. |