GNOME Bugzilla – Bug 351569
Orca does not provide access to Unlock Keyring dialog in Evolution 2.7
Last modified: 2008-07-22 19:18:54 UTC
Please describe the problem: The first time I launch Evolution after booting, I am presented with the Unlock Keyring dialog. It's appearance is not announced, nor is moving focus from object to object within that dialog. Having entered my Keyring password and left the dialog, Orca resumes working as expected. Steps to reproduce: 1. Save at least one password within Evolution 2. Boot 3. Launch Orca 4. Launch Evolution Actual results: The Unlock Keyring dialog appears but it's presence is not announced. Expected results: Orca would announce the presence of this dialog, along with any focus changes within it. Does this happen every time? Yes Other information: I am using the latest (Aug 15th) build of Orca from CVS Head and Evolution 2.7.91 on Ubuntu Edgy.
It seems as though others are also having issues with this dialog on edgy. Here are a couple links of potential interest I found while searching the ubuntu forums. Perhaps we should file a bug with the ubuntu community to get them to make this dialog accessible. I'll also try the gnome keyring manager to see if it is at least a way to work around the problem. https://launchpad.net/distros/ubuntu/+source/gnome-keyring/+bug/54779 http://www.ubuntuforums.org/showthread.php?t=187874
Created attachment 73042 [details] Orca debug.out generated whilst recreating this problem. This was on Ubuntu Edgy Eft (Knot-2) last night.
If you have the "Save Password" checkbox checked on the mail account password dialog, then a program called gnome-keyring-ask is started. I believe the problem here is that gnome-keyring-ask just calls gtk_init rather than gnome_program_init() so the dialog that is presented is inaccessible. I tried the following: % cd /usr/lib/gnome-keyring % sudo mv gnome-keyring-ask _gnome-keyring-ask I then created a small bash script /usr/lib/gnome-keyring/gnome-keyring-ask containing the following: #!/bin/bash export GTK_MODULES="gail:atk-bridge" /usr/lib/gnome-keyring/_gnome-keyring-ask $* but that didn't fix the problem. Still investigating...
Recent versions of gnome-session set the GTK_MODULES environment variable to include gail and atk-bridge already. If "echo $GTK_MODULES" doesn't show this on your system, then something is wrong with either gnome-session or the way your gconf key is being set - or your distro is somehow stripping out the relevant GTK_MODULES-setting code.
On the other hand, if this is a sudo app, and the GUI is running as root, the problem is the same as the following RFE: http://bugzilla.gnome.org/show_bug.cgi?id=163132 in short, sudo apps aren't accessible because bonobo-activation-server only works on a per-user basis. We plan to fix this for gnome 2.17/2.18, which is the subject of a number of ongoing patches
Thanks Bill. This isn't a sudo app. It's running as a normal user. $GTK_MODULES is set to gail:atk-bridge This problem appears on latest Ubuntu Edgy Eft (Knot-2); a GNOME 2.16 system. I'll keep looking.
Hi Rich. As I mentioned to you via email a week or two ago, Orca spoke the Unlock Keyring dialog once. It happened again the other day. And just now it occurred twice! The problem is that I cannot reproduce it intentionally. <sigh> What *seems* to be the common element is giving another window focus at around the same time -- perhaps at the very same time -- that the Unlock Keyring dialog appears: The first time Orca spoke the dialog, I had launched Orca, launched Gaim, launched Evolution and then immediately used the mouse to drag the Gaim window to a different monitor. The second time Orca spoke the dialog, I had launched Orca, launched Gnome Terminal, launched Evolution, and then immediately Alt Tabbed back to the terminal window. Just now, I had launched Orca, launched Firefox, used Alt D to get to the Address Bar, launched Evolution, and then immediately Alt Tabbed back into Firefox. On all of these occasions, I have rebooted and tried to reproduce the results without success (save this last time where I was able to reproduce it again, but only once out of five attempts). I realize that this is vague information, and I will keep trying to find a way to reproduce it reliably. In the meantime, I figured it wouldn't hurt to pass it along....
Okay, it just spoke again. I kid thee not. Here's what I did: 1. Launched Orca from the Applications menu via keyboard 2. Launched Skype from the Applications menu via keyboard 3. Selected "Evolution Mail" from Applications ... Internet via keyboard 4. Immediately upon pressing Enter on Evolution Mail, used the mouse to click on the Skype title bar, keeping the mouse button held down until the Unlock Keyring dialog appeared. 5. Used the mouse to give focus to the Unlock Keyring dialog Result: Orca spoke the dialog. Tabbing from field to field caused Orca to correctly announce the field with focus. 6. Alt Tabbed back to Skype and then back to the Unlock Keyring dialog. Result: Orca no longer speaks it. Odd.... But promising!
Thanks Joanie. Any chance you can try reproducing this with debug turned full on and attach the resulting debug.out to this bug report please?
Created attachment 73644 [details] debug.out request by Rich Rich: Because I'm admittedly lazy when it comes to generating unique passwords for everything, I edited the debug.out key events in which I typed my password replacing the actual letter with an 'x'. I was careful to leave everything else untouched. I hope that's okay. This is the result of doing the Skype test again. I even tabbed around for good measure and tried sayAll and whereAmI prior to entering my password. HTH!!
No problem. In fact, that's *exactly* what I did too for the first attachment to this bug. It's the actual SPEECH lines and the events leading up to them that I'm interested in. Thanks.
The more I look at this, I'm convinced it's the same problem as bug #344192. I'll see if a gnome-keyring-ask script with a similar locusOfFocusChanged() method, fixes the problem.
Created attachment 73913 [details] [review] Patch to fix the problem. It was a similar problem to bug #344192. I created a gnome-keyring-ask.py script that subclassed the locusOfFocusChanged() method and set the old locus of focus to None before calling locusOfFocusChanged() in default.py.
Changes checked into CVS HEAD. Closing as FIXED. Joanie, if you get a chance could you try it out please? If it's still got problems for you, just let me know. Thanks.
Rich I built from CVS as soon as I saw the patch. (You're predictable in that regard.) ;-) This is a fix worthy of champagne!!!! Works great thus far! Thanks!