SUMMARY I am unable to navigate Qt and KDE apps running as a flatpak using the Orca screen reader in a GNOME desktop session. I have not tested this when running under a KDE desktop session. However if I run the flatpak from a terminal with the command-line arguments --no-a11y-bus --talk-name=org.a11y.Bus, then the app is accessible with Orca. STEPS TO REPRODUCE 1. Log into a GNOME session (I am using GNOME 41 on Fedora 35). 2. Enable Orca. This can be done with the Alt + Super + S shortcut key. (Make sure you have working audio to hear spoken text) 3. Install a Qt/KDE app from flathub, as above, org.kde.dolphin is a good test candidate here. 4. Either load dolphin from the activities overview, or run "flatpak run --user org.kde.dolphin" in a terminal. OBSERVED RESULT Dolphin loads, but when navigating the app with the keyboard, you do not hear any spoken text from Orca. EXPECTED RESULT Orca should read the files and folders that you navigate to with the keyboard. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 5.16.18-200.fc35.x86_64, GNOME 41, latest version of org.kde.Platform 5.15-21.08 from flathub. KDE Plasma Version: KDE Frameworks Version: 5.15-21.08 Qt Version: 5.15 ADDITIONAL INFORMATION A workaround is to run "flatpak run --user --no-a11y-bus --talk-name=org.a11y.Bus org.kde.dolphin" in a terminal. Doing this, Orca should read the files and folders that you navigate to with the keyboard. I suspect the problematic commit is 7800017d67f93f7e93f7294b91a1048cf933a39f from https://invent.kde.org/qt/qt/qtbase.git. It should also be noted that running a GTK 4 app like org.gnome.TextEditor works fine without any tweaking. So far as I know, GTK 4 does use the AT_SPI_BUS_ADDRESS environment variable, and all works well.
Qt was patched to support AT_SPI_BUS_ADDRESS recently, so this needs investigation. https://invent.kde.org/qt/qt/qtbase/-/commit/7800017d67f93f7e93f7294b91a1048cf933a39f
Does it work with non-Flatpak Qt apps?
(In reply to Nicolas Fella from comment #2) > Does it work with non-Flatpak Qt apps? I am able to use Qt apps on the host system with Orca just fine, bearing in mind that in GNOME at least, the AT_SPI_BUS_ADDRESS variable is not set, as there are other discovery mechanisms in place to allow for the at-spi dbus socket to be found. So far as I understand it, AT_SPI_BUS_ADDRESS is used specifically by flatpak to proxy the at-spi dbus socket through to the sandbox.
(In reply to Luke Yelavich from comment #3) > (In reply to Nicolas Fella from comment #2) > > Does it work with non-Flatpak Qt apps? > > I am able to use Qt apps on the host system with Orca just fine, bearing in > mind that in GNOME at least, the AT_SPI_BUS_ADDRESS variable is not set, as > there are other discovery mechanisms in place to allow for the at-spi dbus > socket to be found. So far as I understand it, AT_SPI_BUS_ADDRESS is used > specifically by flatpak to proxy the at-spi dbus socket through to the > sandbox. Could you test setting `AT_SPI_BUS_ADDRESS` on the host (with latest Qt5 that has this change) to the host address. You can get it with `gdbus call -e -d org.a11y.Bus -o /org/a11y/bus -m org.a11y.Bus.GetAddress`. Then export `AT_SPI_BUS_ADDRESS=unix:path=/run/user/1000/at-spi/bus_1,guid=37f2237a76e844fd76e4ab94622a3609` for example. If this works then Qt is using the env var fine and the problem is the flatpak proxy permissions. If this fails then the patch using the env var is likely incorrect.
(In reply to tingping from comment #4) > Could you test setting `AT_SPI_BUS_ADDRESS` on the host (with latest Qt5 > that has this change) to the host address. > > You can get it with `gdbus call -e -d org.a11y.Bus -o /org/a11y/bus -m > org.a11y.Bus.GetAddress`. > Then export > `AT_SPI_BUS_ADDRESS=unix:path=/run/user/1000/at-spi/bus_1, > guid=37f2237a76e844fd76e4ab94622a3609` for example. > > If this works then Qt is using the env var fine and the problem is the > flatpak proxy permissions. If this fails then the patch using the env var is > likely incorrect. I don't *think* it is anything to do with flatpak, because GTK 4 apps work just fine, and a glance at GTK 4 code shows that AT_SPI_BUS_ADDRESS is used. However, I will humor you, and will check host Qt, and will do a local patched build if need be.
The below was run on the host Linux install, which is now Fedora 36. I set AT_SPI_DBUS_ADDRESS after getting it from a gdbus command and then ran dolphin: [themuso@barton ~]$ gdbus call -e -d org.a11y.Bus -o /org/a11y/bus -m org.a11y.Bus.GetAddress ('unix:path=/run/user/1000/at-spi/bus_0',) [themuso@barton ~]$ export AT_SPI_BUS_ADDRESS=unix:path=/run/user/1000/at-spi/bus_0 [themuso@barton ~]$ dolphin Qt: Session management error: networkIdsList argument is NULL libpng warning: iCCP: known incorrect sRGB profile Prior to setting AT_SPI_BUS_ADDRESS, I ran dolphin, and could navigate files/folders with spoken output from Orca. After setting AT_SPI_BUS_ADDRESS as above, Orca did not speak anything when navigating files/folders in Dolphin. Unsetting AT_SPI_BUS_ADDRESS returned the previous behavior, with Orca providing spoken output. So to me here, it appears to be something in Qt. Setting AT_SPI_BUS_ADDRESS seems to not quite be enough for Qt's at-spi backend to function.
There is a race condition inside Qt somewhere. AT_SPI_BUS_ADDRESS definitely doesn't work as-is BUT delaying it with a qtimer for 1 second makes it work. Also, related observation: due to the async dbus nature of the regular call path (without the env var) there is an inherent delay that likely hides the race condition fairly reliably.
https://codereview.qt-project.org/c/qt/qtbase/+/422290
That Qt patch was merged (thanks Harald!). Is there anything left to do here, or does that fully fix the bug?
FYI, harald's patch has been backported to KDE's Qt Patch Collection.
Can confirm the patch works, after updating flatpaks using Qt5 here. Thanks all.