GNOME Bugzilla – Bug 347124
Orca hangs when attempting to access apps started via gksu
Last modified: 2008-07-22 19:13:21 UTC
The gksu utility is used to launch applications as root, and users encounter it when attempting to run an application such as Ubuntu's "synaptic" from the launch menu (i.e., gksu is the app that pops up a GUI asking you for a password to run something as root). When an application is launched via gksu, Orca attempts to access the application via a call to getChildAtIndex on the desktop object and the call will hang, hanging Orca. As a workaround to prevent the hang, users can launch the application from a command line prompt. Note that this does not provide access to the application (a fix for AT-SPI is being proposed for that). This is not necessarily an Orca bug, but it is something we discovered recently and I want to make sure we at least have it written down somewhere.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report and for your fix. :-)
Whoops! Closed the wrong bug.
See also related work: http://bugzilla.gnome.org/show_bug.cgi?id=163132 https://wiki.ubuntu.com/Accessibility/Specs/SudoAdminAtspi
Tracking...
Add accessibility keyword. Apologies for spam.
This one probably is Linux specific. Note adjusting OS field.
Additional info: one can cause this hang w/o Orca. Do the following: gksu gedit& (wait for gedit to come up) at-poke (at-poke will hang)
Additional info: the hang appears to be related to the fact the gksu grabs the kayboard by default. One can disable this via: gconftool-2 --type bool --set /apps/gksu/disable-grab "true" This prevents the hang, but Orca stops speaking while the app is up and running. Coupling disabling the grab with the fix for http://bugzilla.gnome.org/show_bug.cgi?id=163132 might work, however.
(In reply to comment #8) > Additional info: the hang appears to be related to the fact the gksu grabs the > kayboard by default. One can disable this via: > > gconftool-2 --type bool --set /apps/gksu/disable-grab "true" > > This prevents the hang, but Orca stops speaking while the app is up and > running. Coupling disabling the grab with the fix for > http://bugzilla.gnome.org/show_bug.cgi?id=163132 might work, however. As an alternative to requiring users to do this, we will provide a checkbox in the "General" preferences tab that allows the user to "Disable gksu keyboard grab". Since the grab is for security purposes, we will not disable it by default.
Created attachment 79290 [details] [review] Patch to implement the suggestion in comment #9. Changes checked into SVN trunk. It seems to work nicely. Before I close the bug as FIXED, could others please let me know if there are any changes needed (i.e. different location on the General Orca Preferences tab) or problems. Thanks.
Adjusting the summary as this bug is no longer blocked.
Only one really minor change to the dialog. Could you make the keyboard layout the first in the tab order ? I think this is the option that users will change most often. thanks
Created attachment 79294 [details] [review] Move keyboard layout to be the first item on the General preferences pane. No problem. Done. Changes checked into SVN trunk. As Will mentioned, we'll need to keep this bug open until we've had a chance to check that everything works with GNOME 2.17 (eg. an announced "stable" Ubuntu Fiesty build).
Mike just phoned be and says that this works great. Thanks! Closing it as FIXED.
Well it looks like I shouldn't have done that last python-dbus update. The update-manager just crashes every time now (even after a reboot). GTK Accessibility Module initialized Traceback (most recent call last):
+ Trace 105476
app = UpdateManager(data_dir)
self.setupDbus()
'/org/freedesktop/UpdateManagerObject')
follow_name_owner_changes=follow_name_owner_changes)
_dbus_bindings.UInt32(0))
reply_message = self._connection.send_message_with_reply_and_block(message, timeout)
Ignore that last comment. It should have been for bug #400763.