GNOME Bugzilla – Bug 756827
orca would speak password in lightdm-gtk-greeter
Last modified: 2015-10-20 21:18:35 UTC
Created attachment 313697 [details] [review] proposed fix Hello, Source: http://bugs.debian.org/800602 When lightdm-gtk-greeter is configured with [SeatDefaults] greeter-hide-users=false Orca would speak the letters of the password being typed. This seems to be because by default Orca sets the locus on the application frame, and not on the object, and thus it doesn't notice that it's already a password object, for which keypresses should not be echoed! Apparently this is avoided in gdmlogin by overriding onWindowActivated(). The proposed attached fix simply copies that implementation over for lightdm-gtk-greeter. It'd however be probably a good thing to try to generalize this, because all DMs will suffer from the same issue...
(In reply to Samuel Thibault from comment #0) > Orca would speak the letters of the password being typed. This seems to be > because by default Orca sets the locus on the application frame, Yes. For two reasons: 1. It is expected that the application will then emit a focused-changed event on the focused widget. (I'm guessing that lightdm-gtk-greeter fails to do so?) 2. If Orca looked for the focused object as a general rule, Orca users would experience significant delays in presenting most newly-activated windows. There is no API to ask an application for the currently-focused widget, so a tree dive is required. > Apparently this is avoided in gdmlogin by overriding onWindowActivated(). > The proposed attached fix simply copies that implementation over for > lightdm-gtk-greeter. Thanks for the patch. Given what you say here: > It'd however be probably a good thing to try to generalize this, because all > DMs will suffer from the same issue... I am going to hold off on committing it and give this issue some more thought.
> > Orca would speak the letters of the password being typed. This seems to be > > because by default Orca sets the locus on the application frame, > > Yes. For two reasons: > > 1. It is expected that the application will then emit a focused-changed event > on the focused widget. (I'm guessing that lightdm-gtk-greeter fails to do so?) Why would it? orca gets started after lightdm-gtk-greeter, so it's up to orca to find out what it needs to show. Really, this is the same case as gdmlogin. > 2. If Orca looked for the focused object as a general rule, Orca users would > experience significant delays in presenting most newly-activated windows. I'm talking about the initial research, when Orca starts up. I.e. typically DM banners or desktop startup.
> I am going to hold off on committing it and give this issue some more thought. Well, in the meanwhile this is a security issue for our users...
(In reply to Samuel Thibault from comment #3) > > I am going to hold off on committing it and give this issue some more thought. > > Well, in the meanwhile this is a security issue for our users... Understood. I didn't say I was going to wait for years. I may even do an alternative solution today. In the meanwhile, I don't see adding a new script just to delete it a little while later. I trust you can solve this security issue immediately for your users in your downstream Orca package.
I've made some changes in Orca master to update the state when keys are pressed and when there's text changes in a password field -- even if it's not a greeter. Could you please test master and see if it resolves your specific problem with lightdm-gtk-greeter?
Yes, the change fixes the issue (and applies cleanly on 3.14 we have in Debian Jessie).