GNOME Bugzilla – Bug 535827
Automatically load gail:atk-bridge if AT_SPI_IOR is set on root window
Last modified: 2010-03-02 07:16:04 UTC
One of the issues we run into with accessibility support is the need for GTK_MODULES to be set in the environment that launches GTK+ applications. In most cases, it's done as the user and the user's environment can easily be modified to include GTK_MODULES. However, when displaying applications as another user on the display (e.g., a sysadmin application running as 'root'), it can be necessary to ensure GTK_MODULES is set for those application environments. Instead of this, would it be acceptable to modify GTK+ to automatically load gail and atk-bridge if it detects the AT_SPI_IOR property on the root window? The presence of this property is an indication that accessibility is needed and can be used to eliminate the dependency on GTK_MODULES for this purpose.
Hi Matthias, where do you think is the proper place to add these code? I think we can: 1. get the module list from GTK_MODULES, if libgail and atk-bridge is not there, check AT_SPI_IOR on the root window. If the IOR is set (means accessibility is enabled), add libgail and atk-bridge to the module list. And then load modules in the module list. 2. after loading the module list, check if libgail and atk-bridge is loaded, if not, check the IOR, if the IOR is set, load the 2 modules. 3. do you have any suggestion?
Created attachment 117183 [details] [review] patch Change the category to gtk+ and paste a patch.
Created attachment 117187 [details] [review] update patch
This really shouldn't be necessary once we switch to using the xsetting for setting modules.
Is there a plan for xsetting?
I remember there is still a problem for the patch. Please let me know if we still need such kind of patch and I will work a new one.
(In reply to comment #4) > This really shouldn't be necessary once we switch to using the xsetting for > setting modules. Hi Matthias: This patch will benefit a number of things and would be useful for GNOME 2.24. So, I'm curious if your comment means "don't apply this patch" or if it means "this is an acceptable patch for GNOME 2.24? :-)
No, I don't think this is an acceptable patch. See bug 539840 for the approach I prefer.
> See bug 539840 for the approach I prefer. I see how bug #539840 interacts with applications running on the desktop as the user that is currently logged in, but I'm not sure how it solves the problem of an application running as a different user. The proposal for this bug is to make the loading of the accessibility modules based upon what the desktop wants (i.e., the presence of AT_SPI_IOR) versus just the user configuration. This helps eliminate the requirement that every user that might present an application on the desktop be configured to match the a11y preferences of the user currently logged in. The main use case for this is helping to ensure that administrative GUI's running as root are accessible. I might be missing something, though. Can you explain how bug #539840 will solve the main use case we're trying to solve here?
running gtk applications as root is not recommended in the first place.
but it is done and users need access
xsettings are per screen. As long as your root gtk app displays on the same screen, it will share the same xsettings.
Thanks! Let me make sure I understand... 1) The gnome-settings-daemon sets up gtk-modules XSETTING information based upon what's in the gconf for the user who owns the session. (See http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html for info on XSETTING). 2) Any GTK+ client (running as any user) that can connect to the display from any machine reads the gtk-modules XSETTING information from the display and takes appropriate action. If this is the case, it's definitely a much more generic way to get around needing GTK_MODULES. Now...to think about what Qt will do to determine that it needs to enable a11y support when connecting to the display. I guess they'll need to set up their own sort of thing to do this.
Here is a schemas file that will have to be installed from some suitable module, to make this work. <?xml version="1.0"?> <gconfschemafile> <schemalist> <schema> <key>/schemas/apps/gnome_settings_daemon/gtk-modules/gail:atk-bridge</key> <applyto>/apps/gnome_settings_daemon/gtk-modules/gail:atk-bridge</applyto> <owner>gnome</owner> <type>string</type> <default>/desktop/gnome/interface/accessibility</default> <locale name="C"> <short>GTK+ modules for accessibility support</short> <long>This key determines the GTK+ modules to load for accessibility support.</long> </locale> </schema> </schemalist> </gconfschemafile> Where do you want this to live ? One option would be control-center, with the a11y capplet.
To me, the package where the at daemon lives (ie. at-spi) looks like the most natural place to put this. Failing that, I could also agree with shipping it with g-s-d.
Li, does that sound acceptable to you ? I can probably cook up a complete patch to add the necessary glue to at-spi configure.in / Makefile.am if you're ok with this.
Sorry for late response, I am just back from vacation. Yes, I am OK with it.
Created attachment 118981 [details] [review] a complete patch Here is a patch that adds the schemas file and the necessary glue to install it. Ok to commit ?
Yes. But it is in hard code freeze now, should we send release team a mail first?
Yes, we should. I just wanted to get your ok first.
OK. Thanks.
2008-09-19 Matthias Clasen <mclasen@redhat.com> Bug 535827 Automatically load gail:atk-bridge if AT_SPI_IOR is set on root window * at-spi.schemas.in: Add a GConf schema for a key that makes gnome-settings-daemon add the a11y modules to the gtk-modules xsetting. * configure.in: * Makefile.am: Necessary glue to install the schemas file.
I just wanted to chime in and confirm that this approach fixes the gnome-session logout dialog. I did: 1) enable orca 2) start gedit 3) type some characters 4) gnome-session-save --logout-dialog As expected, it wasn't noticed by orca. 5) gconftool-2 --set /apps/gnome_settings_daemon/gtk-modules/gail:atk-bridge --type string /desktop/gnome/interface/accessibility 6) logged out and logged back in 7) repeated steps 2-4 Then orca worked!
Woo hoo! Thanks for testing, Ray! Sorry to be ignorant about this, but will GNOME 2.24 be set up so users don't have to directly (or indirectly) do the gconftool-2 command? Will (In reply to comment #23) > I just wanted to chime in and confirm that this approach fixes the > gnome-session logout dialog. > > I did: > > 1) enable orca > 2) start gedit > 3) type some characters > 4) gnome-session-save --logout-dialog > > As expected, it wasn't noticed by orca. > > 5) gconftool-2 --set /apps/gnome_settings_daemon/gtk-modules/gail:atk-bridge > --type string /desktop/gnome/interface/accessibility > 6) logged out and logged back in > 7) repeated steps 2-4 > > Then orca worked! >
yea, that's what the schema is about. Looks like mclasen commited it today too, so we're all set.
I.ve done the mentioned steps but orca does not work. First I have upgrade ubuntu intrepid to latest ersions. 2. upgraded at-spi from svn trunk 3. fired up the mentioned gconftool-2 command 4. restarted the machine. 5. tried to run applications with sudo 6. tried the logoff/shutdown dialog Result: The testcases were not successfgull. Orca says inaccessible.
(In reply to comment #26) > I.ve done the mentioned steps but orca does not work. > First I have upgrade ubuntu intrepid to latest ersions. > 2. upgraded at-spi from svn trunk > 3. fired up the mentioned gconftool-2 command > 4. restarted the machine. > 5. tried to run applications with sudo > 6. tried the logoff/shutdown dialog > > Result: > The testcases were not successfgull. Orca says inaccessible. I just upgraded my Ubuntu Intrepid box tonight to the latest bits and rebooted. When I ran orca and logged out, Orca didn't speak the dialog. But, it worked after I ran the gconftool-2 command from step 5 in comment #23: gconftool-2 --set /apps/gnome_settings_daemon/gtk-modules/gail:atk-bridge --type string /desktop/gnome/interface/accessibility This made me think that perhaps the at-spi schemas change didn't make it in to at-spi-1.24.0. In looking at the at-spi-1.24.0 source tarball, though, it's in there, and it *should* end up in /etc/gconf/schemas/at-spi.schemas getting created as long as --sysconfdir=/etc when you build at-spi. So, I'm going to guess maybe something got messed up in the Ubuntu distribution and /etc/gconf/schemas/at-spi.schemas. I'm going to dig a little deeper, though, and make sure that a properly built/installed at-spi-1.24.0 ends up giving the desired behavior.
(In reply to comment #27) > So, I'm going to guess maybe something got messed up in the Ubuntu distribution > and /etc/gconf/schemas/at-spi.schemas. I'm going to dig a little deeper, > though, and make sure that a properly built/installed at-spi-1.24.0 ends up > giving the desired behavior. > Well...I built/installed at-spi-1.24.0 after issuing this configure line: ./configure --prefix=/usr --libexecdir=/usr/lib/at-spi --sysconfdir=/etc I ended up with /etc/gconf/schemas/at-spi.schemas in place, and I also verified accessibility was enabled for my desktop session. I then used gconf-editor to unset my per-user gconftool-2 setting for /apps/gnome_settings_daemon/gtk-modules. I then logged out and logged back in. Unfortunately, when I logged out, the logout dialog was not accessible. When I reset the /apps/gnome_settings_daemon/gtk-modules property, however, the logout dialog became accessible: gconftool-2 --set /apps/gnome_settings_daemon/gtk-modules/gail:atk-bridge --type string /desktop/gnome/interface/accessibility So, I'm now suspecting that the schema isn't working properly. I don't know enough about them, however, to understand whether they are really at fault or if something else is going wrong. I'm reopening this bug with the hopes that Matthias or Ray can lend some insight.
I suspect gconf_client_all_entries() is ignoring schema defaults.
did at-spi have a schema before? If it didn't, the ubuntu packager may forgotton to add gconftool-2 --makefile-install-rule ... as a post installation step in the package. Can you confirm that the schema is installed by doing: gconftool-2 --get-schema-name /apps/gnome_settings_daemon/gtk-modules/gail:atk-bridge If it's not installed it will yell. Could be there's a bug in GConf like Jens mentions as a possibility, too, though. Not sure.
I'm guessing this is a packaging bug, because when I'm on a rawhide machine and I do: gconftool-2 --recursive-unset /apps/gnome_settings_daemono/gtk-modules (to undo the gconftool call from my test above) and then do gconftool-2 -R /apps/gnome_settings_daemon/gtk-modules (which presumably does something similar to the g-s-d code) then I get: gnomebreakpad = true gail:atk-bridge = /desktop/gnome/interface/accessibility which comes from the schemas and seems right.
(In reply to comment #31) > I'm guessing this is a packaging bug, because when I'm on a rawhide machine and > I do: > > gconftool-2 --recursive-unset /apps/gnome_settings_daemono/gtk-modules Ha! This one had me fooled until I saw the "daemono" spelling. :-) Yep, if I do a --recursive-unset and then do the --recursive-list (gconftool-2 -R) command, I don't get any output. So...thanks tons for the insight on this. Very useful. Let's talk about the packaging issue. :-) What *should* be going on, and is this something that should be part of the make install for at-spi?
So the makefile probably already does it, but that's not sufficient. That's more of a bone for people building from source. When distributions package schema files they have to be installed at installation time, not build time so they'll end up in the user's gconf database instead of some gconf database on the build machine or stuffed into the package. In rpm based distros it's normally done as a %post script: export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule /etc/gconf/schemas/at-spi.schemas Different distributions handle this different ways. I'm sure Ubuntu already has established conventions for dealing with schema files. Probably just a minor package bug that needs to get fixed. Sebastien, do you have any insight?
right the ubuntu package who did the at-spi update forgot to list the schemas as something to install so it's not used right now, I'll point him to this bug
I dont Know if this is related to this bug. Setting the mentioned schema breaks firefox accessibility under orca. I can reproduce this on my machine. When I unset gtk-modules using gconf-editor firefox works again.
(In reply to comment #35) > I dont Know if this is related to this bug. > Setting the mentioned schema breaks firefox accessibility under orca. > I can reproduce this on my machine. > When I unset gtk-modules using gconf-editor firefox works again. I can confirm this. Ginn, do you have any ideas what Firefox/Gecko might be doing so as to misbehave in this new world order?
Will, Firefox / Gecko loads gail and atk-bridge by itself. Since gail and atk-bridge can only be initialized once for one process. Firefox / Gecko have to make sure gail and atk-bridge are not loaded before its own loading. So it clears libgail and atk-bridge from GTK_MODULES at startup. But it won't work with the fix of this bug.
(In reply to comment #37) > Will, > > Firefox / Gecko loads gail and atk-bridge by itself. > Since gail and atk-bridge can only be initialized once for one process. > Firefox / Gecko have to make sure gail and atk-bridge are not loaded before its > own loading. > So it clears libgail and atk-bridge from GTK_MODULES at startup. > > But it won't work with the fix of this bug. Eeeks. That was my fear. I remember seeing some code in Firefox at one point that messed around with GTK_MODULES. I searched for it the other day, but couldn't find it, so I wasn't sure if that still existed or not. Ray, Matthias: do you have any suggestions for how Firefox might bypass GTK's automatic loading of gail and atk-bridge (or any solutions for how Firefox might be modified to work with this new behavior)? Alternatively, Li and Ginn, I wonder if there is something that might be done in gail to allow it to be modified post-module-load so that Firefox can do the tricks it needs to do.
I suggest firefox should stop messing with this...
Alternatively, if they really have to do this, they can override the setting a la g_object_set (settings, "gtk-modules", "", NULL) Although it may be hard to do that before gtk has done the module loading.
Actually, whats needed is debugging the problem that caused this workaround to be committed to the mozilla codebase. See https://bugzilla.mozilla.org/show_bug.cgi?id=312092
If I recall, Li and I have looked at the issue, the result is some registries of CORBA doesn't work for second call of same process. I think the right way to go is to make 2 a11y toolkits work together, no matter which one was loaded firstly. But it may be hard, and requires a lots of changes. Before it is done, we should have a way to let Firefox escape from the automatically loading of gail:atk-bridge.
On my Machine (intrepid with all updates) the development branch of firefox works as expected. Is the mentioned firefox bug fixed in firefox (minefield)?
(In reply to comment #43) > On my Machine (intrepid with all updates) the development branch of firefox > works as expected. > Is the mentioned firefox bug fixed in firefox (minefield)? It may be that Ubuntu backed out the schemas. Do your logout/shutdown dialogs still work?
See also bug #555466, where miracle worker Joanie appears to have managed to come up with a workaround for at least Orca/FF. I believe this is because Orca looks mostly at AT-SPI events and looks upward from them and we're getting lucky. We will still see issues with FF with things that start at the top of the hierarchy and look downward. These things include accerciser and GOK. So, some more work is still needed to resolve the FF issue.
gtk_modules are loaded when gdk_display_manager_set_default_display() is called. before firefox calls it, we can do gtk_settings_get_for_screen(gdk_display_get_default_screen(display)) and get setting string for gtk-modules, strip atk-bridge, and set it back. it's just something like strip atk-bridge off GTK_MODULES env variable. I've tested it on ubuntu 8.10 beta. If it's the fix we'd like to use, I'll post the patch on b.m.o. Comments?
Its still not a fix, just a workaround for some problem inside firefox. Better than nothing, of course.
Firefox/Gecko uses its own A11y toolkit, meanwhile it uses gail for the GTK+ dialogs. Atk-bridge doesn't provide a method to make it work gracefully without hacking.
The patch is posted at https://bugzilla.mozilla.org/show_bug.cgi?id=460926
(In reply to comment #47) > Its still not a fix, just a workaround for some problem inside firefox. > Better than nothing, of course. The main problem is that Firefox needs to delay the initialization of the ATK bridge. The main reason is that it is mixing two accessible toolkits (GTK+ and Gecko) and needs to make sure the accessible hierarchy is set up appropriately. Prior to this change, what was happening is that Firefox would delay the initialization of the ATK bridge until after Firefox had the chance to create its top level Accessible application object. This permitted everything to sort itself out and be happy. The way Firefox was delaying the initialization was by removing atk-bridge from GTK_MODULES and then dynamically loading and initializing the atk-bridge module later, bypassing GTK's module mechanisms. What's currently happening with the fix for this bug is that the call to gtk_init is resulting in the ATK bridge getting loaded and initialized very early, causing the ATK bridge to automatically create a top level Accessible object prior to Firefox creating its top level Accessible. This results in unexpected behavior. Li Yuan, Ginn Chen, Brian Cameron, and I talked about options for solving this problem, with the top solutions being: 1) Something similar to the patch Ginn mentions in comment #49, though I think Matthias' recommendation (via Ray in IRC) is that the application should use g_object_set (settings, ...). This ends up being very close to how the GTK_MODULES editing solution worked prior to the change made for this bug. One concern with setting the property was that it might change things globally for all applications. In IRC with Ray, however, Ray indicated this would not be the case (i.e., it's app specific). In testing with Ginn and Li in Beijing, we also verified this. 2) Providing some way to signal the ATK bridge that it should postpone initialization of itself. That is, rather than having gtk_module_init immediately call atk_bridge_init, provide some mechanism for something like Firefox to tell the bridge that it will call atk_bridge_init later. This mechanism could be something such as a global or an environment variable. 3) It appears as though the new gtk-modules setting handling code doesn't result in the gtk_module_init method of modules being called until after the DISPLAY is opened. As such, if it is possible to create the top level Gecko Accessible object *before* the display is opened, things might work. Right now, option #1 seems to be the one that requires the least work and also behaves closest the way things used to behave. It also isolates changes solely to Firefox, allowing us to get a backwards compatible fix out the door quickly. Option #2 seems like a desirable solution for other toolkits like Gecko that may come along in the future (e.g., WebKit). But, it has the disadvantage of requiring changes to both the ATK bridge and the app/toolkit. This requires people to make sure they have the proper versions of both Gecko and ATK, for example. If the new gtk-modules setting handling code indeed doesn't result in the gtk_module_init method of modules being called until after the DISPLAY is opened, option #3 seems like a viable option. I'm not sure if this is possible with Gecko, though. Thoughts?
> What's currently happening with the fix for this bug is that the call to > gtk_init is resulting in the ATK bridge getting loaded and initialized very > early, causing the ATK bridge to automatically create a top level Accessible > object prior to Firefox creating its top level Accessible. This results in > unexpected behavior. Can firefox be changed to detect that there is already a toplevel Accessible and update it instead of creating its own?
(In reply to comment #51) > Can firefox be changed to detect that there is already a toplevel Accessible > and update it instead of creating its own? I'm not sure about this (Ginn would know better), but I'm guessing not. Ginn, do you know the details?
(In reply to comment #52) > (In reply to comment #51) > > Can firefox be changed to detect that there is already a toplevel Accessible > > and update it instead of creating its own? > > I'm not sure about this (Ginn would know better), but I'm guessing not. Ginn, > do you know the details? > It might introduce a race condition, e.g. a new window is opened, both Firefox and gail will add a child to root accessible. Even if we can fix that, we still have other concerns. 1) The change would not be small, which means it's much harder to get into Firefox 3.0.x branch. 2) Orca doesn't like a process change it's personality at runtime. The option #3 in comment #50 means Firefox needs to load and init gail, load and init its own a11y toolkit, before open display. The change is not quite small. Also I'm not sure whether Mozilla community would accept to move such code from a11y module to toolkit/xre. Option #2 is the best option for application developer. But if we couldn't get it into popular distros' FCS of GNOME 2.24, it would require customers to upgrade both Firefox and at-spi. It's a nightmare for supporting. I'm afraid it's already to late to FCS. IMO, we can take option #1 for Firefox. For other programs that have the same issue, they may take option #3, or option #2 if at-spi would support that.
(In reply to comment #53) > (In reply to comment #52) > > (In reply to comment #51) ... > IMO, we can take option #1 for Firefox. Given this analysis, it seems like we should go with option #1, though with Matthias' recommended use of g_object_set used instead of gtk_settings_set_string_property, if I understand Matthias' recommendation properly (I do not understand the inner workings of the code enough to really have an opinion). Thanks!
Hi All: Just noodging on the this one. The overall change that was introduced late in the 2.24 cycle is now reverberating around the accessibility world and it would be great to do the best we can to make sure GNOME 2.24.3 has the fixes that at least GNOME needs. Where are we with this? Will
I've pulled the NO_GAIL envvar into 2.14.7, fwiw.
I have released at-spi 1.24.1 to include NO_AT_BRIDGE. So I think with Firefox' change we are ready to transfer to xsetting.
To make a long bug longer, and because people keep banging on me about OpenOffice and this issue: * OpenOffice -requires- the use of atk-bridge and gail in order to function properly. + this is because we use a GtkWindow for all top-levels, and then map the OO.o / UNO a11y tree (via demand created peers) to atk - which is then bridged to the IPC in the normal way. + remove atk-bridge & there will be no a11y. Frankly, I can't imagine why you wouldn't want gail & atk-bridge - if you have eg. a GtkFileSelector dialog [ which after all, most apps throw up at some stage ] - how will it be accessible without gail eg. ?
Michael -- The change that seems to be giving OpenOffice problems was the removal of the GTK_MODULES env var. OpenOffice appears to check this to see whether it should load the atk-bridge when it really should be looking at the /desktop/gnome/interface/accessibility GConf key or the new gtk-modules XSetting.
Hokay - so; that's fine - but we need a solid way of detecting whether a11y is enabled in the toolkit before we start going to create a ton of peers and interactions that (sadly, but frankly) de-stabilises OO.o substantially. Does atk provide this ? "atk_is_a11y_active" or something ? Can we add a method there, if there is not one already that makes it easy for us - instead of building some increasingly complicated set of criteria in every large app :-)
If I recall, perhaps not correctly, I think one of the main problems is that initialization of the accessibility infrastructure automatically creates a top level accessible if it detects that one does not yet exist. I believe the difficulty we run into is that we cannot pass a parameter to the initialization method to say "don't do this, I'll take care of it." The past method for doing this was to get rid of GTK_MODULES in the environment and then explicitly load the libraries later. The way we do this now is via the new NO_* environment variables because the libraries are now automatically loaded via the new gconf schemas mechanism. I wonder if it might be possible to provide something that is basically a parameter that says "go ahead and initialize yourself, but wait for me to give you the top level object later." If so, I wonder if that would make sense or not?
(In reply to comment #60) > Hokay - so; that's fine - but we need a solid way of detecting whether a11y is > enabled in the toolkit before we start going to create a ton of peers and > interactions that (sadly, but frankly) de-stabilises OO.o substantially. Does > atk provide this ? "atk_is_a11y_active" or something ? This will make ATK depend on Gconf. For now ATK doesn't.
(In reply to comment #61) > > I wonder if it might be possible to provide something that is basically a > parameter that says "go ahead and initialize yourself, but wait for me to give > you the top level object later." If so, I wonder if that would make sense or > not? > atk-bridge and gail are loaded by gtk_init. Applications (Firefox and OpenOffice) don't call the modules initialize functions directly. This will require some changes in Gtk+ I think.
tbh, this is all seriously messed up. Having each app mix-and-match modules according to the quirks of its own a11y support is at odds with having a desktop-wide way of enabling accessibility.
(In reply to comment #64) > tbh, this is all seriously messed up. > > Having each app mix-and-match modules according to the quirks of its own a11y > support is at odds with having a desktop-wide way of enabling accessibility. I couldn't agree more. However, we have a situation where non-Gtk+ applications need to initialize Gtk+ for native theming, but optionally want bits of Gtk+'s accessibility support. Yes, in a pure Gtk+ world this situation wouldn't exist, but unfortunately this isn't the world we live in. Off the top of my head, I can think of two better, cleaner solutions: First, musing on the idea that the current module loading system in Gtk+ isn't a good fit for accessibility, add new functions to Gtk+ specifically for enabling/disabling Gtk+ a11y. Musing on the idea that external apps mainly want to be able to load Gtk+ for theming, add an overload or additional method that calls gtk_init but disables module loading. Then apps like OpenOffice that need to use gail for gnome widgets can load it manually. Of course, modules like breakpad will never be loaded, but maybe that's not an issue. Any other thoughts/ideas?
(In reply to comment #64) > tbh, this is all seriously messed up. > > Having each app mix-and-match modules according to the quirks of its own a11y > support is at odds with having a desktop-wide way of enabling accessibility. I think we need to take a step back and write down the constraints we face (e.g., parameterless module initialization), the issues involved with setting up an a11y hierarchy when multiple toolkits are involved (e.g., which toolkit gets to create/declare the root app accessible object and how do you hook that up?), etc., and try to figure out a recommended solution. I'm not 100% sure, but I think I recall one of the main problems is that the a11y modules will initialize the root a11y hierarchy when they are loaded. This causes problems when mixing toolkits *and* the toolkit that needs to own the root a11y object is not GTK+. If this is the case, then I think we might need to think about delaying the initialization of the root object to sometime after the a11y modules are loaded. The current method that uses these NO_* environment variables provides a means to do this, but I wonder if the initialization of the root object might be separated from the module initialization time and then created in a more lazy/on-demand way?
atk-bridge needs the root object to create application object and register it. So the lazy way means we don't register application at initialization. We might do this when application emits the first event. But I am not sure it there will be any events before application's own accessibility implementation is loaded.
(In reply to comment #67) > atk-bridge needs the root object to create application object and register it. > So the lazy way means we don't register application at initialization. We might > do this when application emits the first event. But I am not sure it there will > be any events before application's own accessibility implementation is loaded. > I doubt it will work. For Firefox, we can't guarantee the first event is emitted by gail or mozilla a11y toolkit. It's possible that the first event is from gail and mozilla a11y toolkit isn't initialized yet.
OK, sounds like lazy initialization won't work. :-( Any other thoughts on how we might accomplish this?
(In reply to comment #66) > (In reply to comment #64) > I'm not 100% sure, but I think I recall one of the main problems is that the > a11y modules will initialize the root a11y hierarchy when they are loaded. > This causes problems when mixing toolkits *and* the toolkit that needs to own > the root a11y object is not GTK+. Will, could you expand on what 'own' means here?
(In reply to comment #70) > (In reply to comment #66) > > (In reply to comment #64) > > > I'm not 100% sure, but I think I recall one of the main problems is that the > > a11y modules will initialize the root a11y hierarchy when they are loaded. > > This causes problems when mixing toolkits *and* the toolkit that needs to own > > the root a11y object is not GTK+. > > Will, could you expand on what 'own' means here? Hmm...well...it's more of who creates the root accessible. When gail is intialized, if the root has not been created, I believe it creates it in gail_util_get_root (the exact path and call sequence for getting there is a bit of an 'xyzzy' joy): http://svn.gnome.org/viewvc/gtk%2B/trunk/modules/other/gail/gailutil.c?view=markup I believe this ends up getting automatically called as a part of GTK+ loading the module. Once created, there's no replacing the root. So, I believe what Gecko does is something like this: 1) Load gail, but avoid triggering the call to get_root: http://mxr.mozilla.org/mozilla-central/source/accessible/src/atk/nsAppRootAccessible.cpp#716 2) Override gail's get_root: http://mxr.mozilla.org/mozilla-central/source/accessible/src/atk/nsAppRootAccessible.cpp#562 http://mxr.mozilla.org/mozilla-central/source/accessible/src/atk/nsAppRootAccessible.cpp#223 3) Finally call the ATK initializer, causing things to be triggered: http://mxr.mozilla.org/mozilla-central/source/accessible/src/atk/nsAppRootAccessible.cpp#573 The above may be a little off, but the basic idea is to load the a11y modules and avoid triggering their init functions until you really want them called. In this case, what they are doing is replacing the GNOME get_root method(s) with Gecko get_root methods, making Gecko the root.
I think the only problem now is how OpenOffice to find if accessibility is enabled, right? Is it possible that OpenOffice calls gconf to check if the key is enabled?
> I think the only problem now is how OpenOffice to find if accessibility is enabled, right? In fact there is no problem in OO.o land around a11y. We've just applied a patch to not check GTK_MODULES, and to not unload gtk if a11y is enabled [ since then we get a crash from an atexit handler sadly ]. cf. http://www.openoffice.org/issues/show_bug.cgi?id=98533
(In reply to comment #73) > > I think the only problem now is how OpenOffice to find if accessibility is enabled, right? > > In fact there is no problem in OO.o land around a11y. We've just applied a > patch to not check GTK_MODULES, and to not unload gtk if a11y is enabled [ > since then we get a crash from an atexit handler sadly ]. > > cf. http://www.openoffice.org/issues/show_bug.cgi?id=98533 Thanks Michael! Just for clarification...what does this all mean for a system that ships with all the GTK+ stuff with the new schemas behavior, but an old OOo? For example, in order for the old OOo to work on a system with the new schemas behavior, do we need to disable the gconf a11y schemas and make sure GTK_MODULES=gail:atk-bridge? The disabling of the gconf a11y schemas is what we've done to handle older versions of FF. The thinking here is to make the trade off between an accessible FF and OOo than the logout screen and gnome-keyring-ask UI. Eventually, however, everyone will be at the new world order. BTW, I'd still like a brainstorm around coming up with the optimal approach to handle the mixing of toolkits (see comment #71). There's been an expression of distaste for the current method, but no suggestions for a better way.
See also: Bug #563943 (NO_AT_BRIDGE fix for atk-bridge module) Bug #565110 (NO_GAIL fix for gail module)
Java access bridge also needs to be changed: * Makefile.am: * acinclude.m4: * configure.in: * jni/Makefile.am: * jni/Makefile.in: * jni/jni-main.c: (JNI_OnLoad), (JNI_OnUnload): Add a JNI library to set NO_AT_BRIDGE for all Java applications. GTK loads gtk modules according to the setting in xsettings, so GTK_MODULES doesn't work now. To make java applications not load atk-bridge, we add a JNI library to set an environmental variable to ask atk-bridge not load itself.
Willie wrote: > Just for clarification...what does this all mean for a system that ships with > all the GTK+ stuff with the new schemas behavior, but an old OOo? It won't work. Then again, the luxury of back-wards compatibility is not trivially extensible to forward-compatibility :-) > For example, in order for the old OOo to work on a system with the new schemas > behavior, do we need to disable the gconf a11y schemas and make sure Not really; the new OO.o will also work on a system with the old GTK_MODULES world - ie. it will be backwards compatible, and I guess you could try setting GTK_MODULES for the old one in the new world - not sure how that will interact. Ultimately, if you upgrade gtk+ you should have space in your soul to upgrade OO.o too I hope :-)
OK - after a short IRC chat with Mattias, we cannot think of a more graceful solution. In addition, all the wheels have been put in motion and code has been put in place for things to work with the new a11y schemas and the environment variable bypass mechanisms for gail, atk-bridge, FF, OOo, Java, etc. Any refinement of the solution would likely require re-tooling all those changes. So I propose we just agree that we'll accept the current solution as the way to move forward. To avoid requiring people to read all the comments in this bug to figure things out, the following comments in this bug report document how things have been done: GTK+: Comment #22 gail/atk-bridge: Comment #75 Gecko: Comment #71 OOo: Comment #73 Java/AWT/Swing: Comment #76 If we're OK with this, I say close this bug as FIXED and put it behind us. If this seems fair, just do it and don't bother adding numerous "I agree" replies. If you do so, this summary comment will end up getting buried. BTW, I must say how wonderful it is to see the whole community working together here. Lots of different people crossed paths and worked together to fix this. Awesome stuff.
One more thing for the summary: see bug #539840 for the mechanism that is used to determine which modules to load.
I found one problem with my Jaunty system: The shutdown and logout dialogs are inaccessible with Orca. I installed latest at-spi from trunk, Ubuntu uses 1.25.5-0ubuntu1 Top panel switch user applet menu works correct. What can I testing? Attila
I applyed Li Yuan second gtk updated patch (2008-08-22 07:41 UTC) my Jaunty system. I used gtk+ trunk age. The shutdown dialog now works correct, Orca now spoken entire dialog my machine. If possible, please commit this patch. Attila
Luke Yelavitch wroted this comment my bugreport with launchpad (https://bugs.launchpad.net/bugs/328473): The schema file is present, and carrying out the suggested steps in the comments you copied all work as expected, however the logout dialogs are still broken, so I guess the problem is somewhere else in the stack. Will, I applyed with comment#3 patch, this is unneed because important thinks is committed? Why work my system the shutdown dialog after apply this patch? Attila
(In reply to comment #82) > Luke Yelavitch wroted this comment my bugreport with launchpad > (https://bugs.launchpad.net/bugs/328473): > The schema file is present, and carrying out the suggested steps in the > comments you copied all work as expected, however the logout dialogs are > still broken, so I guess the problem is somewhere else in the stack. > > Will, I applyed with comment#3 patch, this is unneed because important thinks > is committed? > Why work my system the shutdown dialog after apply this patch? The patch can work but we decide not to do it that way. But I am not sure why the third patch doesn't work on you system.
So this has still an (ancient) gnome-target set. How critical is this?
(In reply to comment #84) > So this has still an (ancient) gnome-target set. > How critical is this? Yikes. This bug was a hairball from hell and ended up resulting in a number of other things that needed to be worked on. See comment #78 and comment #79 for a summary. I think we can close this bug out as FIXED.
No other feedback - Closing as per last comment.