GNOME Bugzilla – Bug 350716
[a11y] Gnome Screen saver password dialog not accessible.
Last modified: 2011-03-06 06:54:25 UTC
The password dialog for the screen saver is not properly read (if at all). You can reproduce this by manually invoking the screen saver while Orca is running and then interacting with the password dialog box. The mechanism for manually invoking the screen saver differs from machine to machine, but is typically located somewhere near or in the mechanism you use to log out of the desktop.
Tracking...
The first thing to notice here is that the screen saver is going to be different for different platforms. For example, with Solaris is using an AT-enabled version of xscreensaver and that works just fine. The password dialog is properly announced and "star" is spoken for each character of your password as you type it in. With Ubuntu Dapper Drake, gnome-screensaver is being used. This has accessibility problems. The password dialog is not properly announced and the actual password is spoken as you type it in. I will attach an Orca debug.out (with my password hopefully suitable munged) to show what's actually happening.
Created attachment 70725 [details] Transcript of Orca debug while using gnome-screensaver on Ubuntu Dapper Drake. On my Ubuntu Dapper Drake system, I started up Orca, then started up gnome-screensaver manually from a terminal window. This debug.out transcript is from when the gnome-screensaver application started up. I hit the right shift key in order to display the password dialog screen (line 4481). One thing to note is that there are "object:state-changed:focused" events. Will I believe has just added code to Orca to now process these. I'll now checkout the latest Orca, rebuild/install and see if that improves things.
I downloaded the gnome-screensaver module from GNOME CVS and had a quick look at it. The GUI for the password dialog is a Glade file .../gnome-screensaver/data/lock-dialog-default.glade One thing here is that the auth-prompt-entry GtkEntry field needs to have a "Labelled By" relationship with the auth-prompt-label GtkLabel. That will at least mean that "Password:" will get spoken when the focus is on the text entry field. While Orca was running and the gnome-screensaver lock dialog was up I printed the accessible component hierarchy (Insert-F7 within Orca) for the current component: --------------------------------------------------------------------------- +-name='gnome-screensaver' role='application' state='' +-name=None role='window' state='ACTIVE ENABLED FOCUSED RESIZABLE SENSITIVE SHOWING VISIBLE' +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' --------------------------------------------------------------------------- In fact the complete accessible component hierarchy for this application (Insert-F8 within Orca) is: --------------------------------------------------------------------------- +-name='gnome-screensaver' role='application' state='' +-name=None role='window' state='ACTIVE ENABLED FOCUSED RESIZABLE SENSITIVE SHOWING VISIBLE' +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' (*)name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' --------------------------------------------------------------------------- This is majorly broken. Visually the focus is in the GtkEntry window, but accessibly, the focus appears to be on the window. We are not seeing the GtkEntry at all. Unfortunately because it's a lock screen, I was unable to run at-poke on it, to see what it through the application accessible hierarchy looked like. Orca is going to be part of GNOME 2.16 and the default screen reader, so it would be nice if this application functioned correctly with it. From the evaluation above, I don't believe it would work correctly with any of the GNOME screen readers available. Transferring to the gnome-screensaver team for further evaluation. For more details of how to install Orca on your system, see section 4 of: http://live.gnome.org/Orca/ Thanks.
Adjusting the summary to better reflect the problem.
The labelled by relation is now fixed in CVS. So, the unlock dialog is embedded in the toplevel window using XEMBED (via GtkSocket/GtkPlug). We maintain a keyboard grab on the toplevel window. There shouldn't be anything wrong with that. So, why doesn't Orca follow the visble focus?
In order for Orca to be able to sensibly braille/speak about the component that current has focus, it needs to be able to access the accessible component hierarchy. As reported in comment #4 above, this is not possible. "Visually the focus is in the GtkEntry window, but accessibly, the focus appears to be on the window. We are not seeing the GtkEntry at all." You need to make sure that you have setup you component hierarchy correctly. If there is a way of running that dialog without being in "lockscreen" mode, try running the at-poke application along side it, to see the current accessible component hierarchy.
Hmm, at-poke doesn't build from CVS. Any chance you can make the orca videos available in something other than WMV format?
at-poke tarballs available under: http://ftp.gnome.org/pub/GNOME/sources/at-poke/0.2/ I'm surprised it isn't just present on your system too. Orca videos are also available in ogg format. See: http://blogs.sun.com/korn/entry/csun_accessibility_sessions_video_now for more details.
I'm hitting bug 353452 and bug 353457. Might be nice to add that link for the Free versions to the Orca wiki.
Good point. I've sent an email to to the Orca wiki maintainers. What Linux distro are you using? Isn't there a binary at-poke already there (or "apt-get"able) that "just works"?
I develop with GNOME from CVS on top of either Fedore Core 5 or Rawhide. They don't seem to have an at-poke available in Core or Extras.
According to Janina Sayka: An easy way, to install Orca on recent Fedora systems (including the current FC5) is: yum --disablerepo='*' --enablerepo=development install orca This command will also pick up brlapi and any missing dependencies. Not at-poke, but at least you'll be able to see the problem we are seeing with gnome-screensaver when Orca is running.
I've done some testing. It seems like the atk tools don't work with out-of-process XEmbed plugs. A good test case is: at-poke gtk+/tests/testsocket where testsocket is from the GTK+ source. It seems like it works fine with "Add Local Active Child" or "Add Local Passive Child" but not with "Add Active Child" or "Add Passive Child". The difference is that "local" the plug and socket are in the same process. Another datapoint is that when I change gs-lock-plug.c to be a subclass of GtkWindow instead of GtkPlug I am able to see a11y info in at-poke (in the child process not the parent socket process).
Any ideas?
At this point, it's probably worth passing this by the atk/gail guys. Adding Will for his take on this.
Will?
Please pass it on to the right folks. (Sorry I missed the e-mail on this a while back). Thanks!
Who are the right folks? Can anyone confirm that AT tools don't support out of process plugs?
The right folks are Bill Haneman and Padraig O'Briain , the folks working on atk/gail. I've no idea what you mean by "out of process plugs".
Moving this over to the atk component for comment. Comment #14 has the relevant information.
Make sure libgail-gnome is being loaded by this application correctly. libgail-gnome is required for out-of-process bonobo component plugins and GtkPlug/GtkSocket. I can't confirm that GtkPlug/GtkSocket works out-of-the-box with libgail-gnome for apps that do not use libbonoboui, but for apps that use BonoboControl it works fine. libgail-gnome is loaded by gnome_program_init(). There are reports that changes to libgnome regressed this behavior in recent Gnome versions, so you will need to investigate this. William, if you set GTK_MODULES=gail:libgail-gnome:atk-bridge and then start at-poke, how does the behavior change? p.s. - you reassigned this bug to me (default owner) when you moved it here for comment. I'd prefer that you not do that unless/until we can identify the issue better. thanks.
The behavior doesn't seem to change when GTK_MODULES is set. Here's the test case: 1. export GTK_MODULES=gail:libgail-gnome:atk-bridge 2. cd gtk+/tests # the tests directory in the gtk+ sources 3. at-poke ./testsocket 4. then in the testsocket gui click either "Add Active Child" or "Add Passive Child" 5. click the Poke button in the at-poke gui 6. Expand "Socket Test" "frame" row in treeview 7. Expand "<no name>" "filler" row in treeview 8. Expand the last row "<no name>" "filler" in treeview 9. Expand the child of that 10. Expand all the children of that You will see that there is no information about the embedded remote GtkPlug. This application is pure gtk+ it doesn't use libgnome. Is there something I'm missing?
hmm, if the socket is out-of-process, then it should be in its own process space, and presumably calls gtk_init. I would expect, then, that it (the socket) would load gtk_modules, and thus register with the at-spi-registryd as a separate, accessible, process. Does at-poke show some "other" process that could be associated with this socket, in this case? If not, then... q: if it loading gail and atk-bridge, but not calling gtk_modules_init? q: is it loading gail/atk-bridge, calling gtk_modules_init, but for some reason failing to register with the bridge? (possible reasons include the prospect that some initial condition for registering w/the bridge, such as creating a "toplevel" window, is not being met...) Bill
Thanks for the help Bill. at-poke doesn't seem to show any information about any other process. I can confirm that the modules are loaded in both the process of the socket (lt-testsocket) and the plug (lt-testsocket_child): % at-poke ./testsocket & % pmap `/sbin/pidof lt-testsocket`|grep 'gail\|atk' 0026e000 20K r-x-- /opt/gnome/lib/gtk-2.0/modules/libatk-bridge.so 00273000 4K rwx-- /opt/gnome/lib/gtk-2.0/modules/libatk-bridge.so 003e6000 296K r-x-- /opt/gnome/lib/gtk-2.0/modules/libgail.so 00430000 16K rwx-- /opt/gnome/lib/gtk-2.0/modules/libgail.so 007aa000 96K r-x-- /opt/gnome/lib/libatk-1.0.so.0.1213.0 007c2000 8K rwx-- /opt/gnome/lib/libatk-1.0.so.0.1213.0 00eeb000 24K r-x-- /opt/gnome/lib/libgailutil.so.18.0.1 00ef1000 4K rwx-- /opt/gnome/lib/libgailutil.so.18.0.1 % pmap `/sbin/pidof lt-testsocket_child`|grep 'gail\|atk' 004be000 24K r-x-- /opt/gnome/lib/libgailutil.so.18.0.1 004c4000 4K rwx-- /opt/gnome/lib/libgailutil.so.18.0.1 009d1000 20K r-x-- /opt/gnome/lib/gtk-2.0/modules/libatk-bridge.so 009d6000 4K rwx-- /opt/gnome/lib/gtk-2.0/modules/libatk-bridge.so 00e97000 296K r-x-- /opt/gnome/lib/gtk-2.0/modules/libgail.so 00ee1000 16K rwx-- /opt/gnome/lib/gtk-2.0/modules/libgail.so 00f83000 96K r-x-- /opt/gnome/lib/libatk-1.0.so.0.1213.0 00f9b000 8K rwx-- /opt/gnome/lib/libatk-1.0.so.0.1213.0 From the source both programs are calling gtk_init() and the child has been allowed to inherit the environment of the parent (for GTK_MODULES).
I should have been clearer about the "other" process part. at-poke shows the other (child) process in the list but poking it doesn't show any information.
Bill, are you able to reproduce this using my test case (in comment #23)?
Adding Li to the cc: as Bill is no longer actively working on GNOME accessibility or supporting atk. Li, could you read please through the comments above (in particular comments #14 and #22-26) and try the .../gtk/tests/testsocket example, and see if you can come up with any ideas for William. Thanks.
The test case should not work because it is using gtksocket/plug. libgail-gnome only makes applications using bonobosocket/plug accessible. In this case we want embedded object be exposed as 'children' of their parent, no matter if they are in the same process. We need Bonobo/CORBA to do the communication. I don't know why we don't have gailsocket/plug in gail. I'm guessing Bill doesn't want gail depands on CORBA or Bonobo. So is it possible that gnome-screensaver uses bonobosocket/plug instead of gtksocket/plug?
Hi Michael, cc-ing you to another bug :) Do you know the history of why we don't implement accessibility on gtksocket/plug?
Li - not really :-) It -should- be possible to write some custom a11y peers in the atk-bridge for Plug/Socket that would use X Properties on the parent & child window respectively to encode a stringified IOR for the a11y peer. I think you'd want to create the new atk peers inside at-spi [ where you have the CORBA dependency ] (or perhaps inside libgail-gnome where you already have both a gtk+ and a CORBA dependency). I would base the work on the code in libgail-gnome, modulo the evil hooks in there gail_bonobo_ui_set_accessible_epv - which do evil things: adding methods to a virtual table etc. Poke at gtk+/gdk/gdkproperty.h wrt. adding properties; and CORBA_ORB_string_to_object and _object_to_string. HTH.
(In reply to comment #31) > Li - not really :-) > It -should- be possible to write some custom a11y peers in the atk-bridge for > Plug/Socket that would use X Properties on the parent & child window > respectively to encode a stringified IOR for the a11y peer. > > I think you'd want to create the new atk peers inside at-spi [ where you have > the CORBA dependency ] (or perhaps inside libgail-gnome where you already have > both a gtk+ and a CORBA dependency). Yes, I thought about that. Normally we don't require applications which don't depend on libbonoboui to load libgail-gnome. And gtk+ dependency is not our long term plan for at-spi. So finding a good place is not easy for me. > > I would base the work on the code in libgail-gnome, modulo the evil hooks in > there gail_bonobo_ui_set_accessible_epv - which do evil things: adding methods > to a virtual table etc. Yeah, I thought the discuss between you and Bill in many years ago :-)
As a datapoint to extend comment #2. With this setup: bash-3.2$ uname -a; orca --version SunOS solaris-devx 5.11 snv_76 i86pc i386 i86pc Solaris Orca 2.21.2pre I believe /usr/X11/lib/xscreensaver/bin/xscreensaver-lock is what is used to lock the display. It is accessible with the setup above.
This is still happening using gnome under gentoo as of today. The gnome about says 2.22.1 -- is there any way to make this work?
I believe this bug is obsolete now and can be closed. Latest Orca (2.23.3) will correctly announce when the focus is in the Password field with the latest gnome-screensaver. Tested on Ubuntu Hardy (GNOME 2.22.X).