| Summary: | Qt/KDE applications not accessible with the Orca screen reader. | ||
|---|---|---|---|
| Product: | [Developer tools] Qt/KDE Flatpak Runtime | Reporter: | Luke Yelavich <themuso> |
| Component: | general | Assignee: | Aleix Pol <aleixpol> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | aacid, nate, nicolas.fella, sitter, themuso, tingping |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Flatpak | ||
| OS: | Linux | ||
| URL: | https://codereview.qt-project.org/c/qt/qtbase/+/422290 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Luke Yelavich
2022-04-01 00:07:58 UTC
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. 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. |