GNOME Bugzilla – Bug 685453
If an application quits the main loop, and restarts it again, accessibility is lost.
Last modified: 2018-02-10 03:40:22 UTC
Ubuntu's installer has a wizard like interface, and uses several different ui files for each page of the install. THe When switching between pages, the installer code quits the main loop before switching the pages, and then starts the main loop again. Commit 5debed5ae247c1dd440cb71d0a6d328df74b0844 added code to shut down accessibility when the main loop quits, however accessibility is initialized at GTK init time, so when the main loop is shut down, accessibility is lost for the rest of that application's running life, even thouhg it may create other windows and re-run the main loop. I don't know why the Ubuntu installer quits and restarts the main loop. The original bug that was filed for this issue can be found at https://bugs.launchpad.net/ubuntu/quantal/+source/gtk+3.0/+bug/1056300.
The reason to start/stop UI main loops is simple - we may support different UI loops. It can be either gtk, qt or ncurses. We let the user to click about, then return control to the state-machine/logic, rinse & repeat. Maybe we should start a nested main_loop and keep it as our lowest level, i.e. stay at level=1. But I couldn't figure out an easy way to start a nested main_loop.
I have a hard time convincing myself that returning from the mainloop to launch a qt or curses ui is a good idea. Anyway, a11y is not the only thing that is lost. We also sync the clipboard and recent files at that point. Using a recursive mainloop might work for now, but those are on the chopping block as well, if certain people have their way.
Another option would be avoiding shutting down a11y for the gtk_main_quit() case, and only do it when GtkApplication->shutdown() is called. Is there any particular reason why we can't try to always start a11y when gtk_main() is called and gtk_main_loop_level == 0? _gtk_accessibility_init() is already a no-op in case it's initialized already.
Sorry if I was not clear. I didn't meant that we mix and match different UI loops in a single execution. It is just that we support multiple front ends (e.g. transmission-gtk, transmission-qt, transmission-cli). Due to inherently plugin architecture the ui (view) is separate from the controller (python application) and hence the simple solution to start/stop the UI loop: play the ui, pause, switch to controller, change models, play ui again. I don't believe we use GtkApplication at the moment. And multi threading with gtk and python is not great for a11y either. In another app (usb-creator), I believe we currently lose a11y when switching to another thread.
With regards to usb-creator, a11y and threads, that problem appears to be solved since GTK now loads accessibility directly via libatk-bridge, so for quantal at least, that is no longer a problem.
Oh, cool. I should close a few bugs then =)
(In reply to comment #3) > Is there any particular reason why we can't try to always start a11y when > gtk_main() is called and gtk_main_loop_level == 0? _gtk_accessibility_init() is > already a no-op in case it's initialized already. We could try, but how high do you think the chances are that reinitializing a11y works ? A code path that has never been tried
(In reply to comment #7) > (In reply to comment #3) > > > Is there any particular reason why we can't try to always start a11y when > > gtk_main() is called and gtk_main_loop_level == 0? _gtk_accessibility_init() is > > already a no-op in case it's initialized already. > > We could try, but how high do you think the chances are that reinitializing > a11y works ? A code path that has never been tried I am not sure how well that will work. In our case all the widgets/labels have already been initiated once & are kept around between starting&stopping the main loop hence the current at-spi logs of "disappearing" labels/widgets.
*** Bug 687688 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.