After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 350716 - [a11y] Gnome Screen saver password dialog not accessible.
[a11y] Gnome Screen saver password dialog not accessible.
Status: RESOLVED OBSOLETE
Product: gnome-screensaver
Classification: Deprecated
Component: dialog
CVS HEAD
Other Linux
: Normal normal
: ---
Assigned To: gnome-screensaver maintainers
gnome-screensaver maintainers
Depends on:
Blocks: 419139
 
 
Reported: 2006-08-10 10:53 UTC by Willie Walker
Modified: 2011-03-06 06:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Transcript of Orca debug while using gnome-screensaver on Ubuntu Dapper Drake. (227.25 KB, text/plain)
2006-08-11 16:11 UTC, Rich Burridge
Details

Description Willie Walker 2006-08-10 10:53:04 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.
Comment 1 Rich Burridge 2006-08-11 15:32:29 UTC
Tracking...
Comment 2 Rich Burridge 2006-08-11 16:00:15 UTC
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.
Comment 3 Rich Burridge 2006-08-11 16:11:39 UTC
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.
Comment 4 Rich Burridge 2006-08-11 17:26:42 UTC
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.
Comment 5 Rich Burridge 2006-08-11 17:27:35 UTC
Adjusting the summary to better reflect the problem.
Comment 6 William Jon McCann 2006-08-21 22:48:59 UTC
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?
Comment 7 Rich Burridge 2006-08-29 18:16:17 UTC
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.
Comment 8 William Jon McCann 2006-08-29 18:32:59 UTC
Hmm, at-poke doesn't build from CVS.  Any chance you can make the orca videos available in something other than WMV format?
Comment 9 Rich Burridge 2006-08-29 18:59:46 UTC
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.


Comment 10 William Jon McCann 2006-08-29 19:13:12 UTC
I'm hitting bug 353452 and bug 353457.

Might be nice to add that link for the Free versions to the Orca wiki.
Comment 11 Rich Burridge 2006-08-29 19:37:39 UTC
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"?
Comment 12 William Jon McCann 2006-08-29 19:42:14 UTC
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.
Comment 13 Rich Burridge 2006-08-30 16:37:53 UTC
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.
Comment 14 William Jon McCann 2006-08-31 18:15:17 UTC
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).
Comment 15 William Jon McCann 2006-09-07 15:05:14 UTC
Any ideas?
Comment 16 Rich Burridge 2006-09-07 16:14:07 UTC
At this point, it's probably worth passing this 
by the atk/gail guys. Adding Will for his take 
on this.
Comment 17 William Jon McCann 2006-09-11 13:52:50 UTC
Will?
Comment 18 Willie Walker 2006-10-18 14:29:04 UTC
Please pass it on to the right folks.  (Sorry I missed the e-mail on this a while back).  Thanks!
Comment 19 William Jon McCann 2006-10-25 21:00:46 UTC
Who are the right folks?  Can anyone confirm that AT tools don't support out of process plugs?
Comment 20 Rich Burridge 2006-10-25 21:28:22 UTC
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".
Comment 21 William Jon McCann 2006-10-26 01:44:01 UTC
Moving this over to the atk component for comment.  Comment #14 has the relevant information.
Comment 22 bill.haneman 2006-10-26 09:01:48 UTC
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.
Comment 23 William Jon McCann 2006-10-26 14:51:20 UTC
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?
Comment 24 bill.haneman 2006-10-26 15:10:23 UTC
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
Comment 25 William Jon McCann 2006-10-26 15:58:50 UTC
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).
Comment 26 William Jon McCann 2006-10-26 16:08:29 UTC
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.
Comment 27 William Jon McCann 2006-11-02 16:46:57 UTC
Bill, are you able to reproduce this using my test case (in comment #23)?
Comment 28 Rich Burridge 2007-08-07 16:21:54 UTC
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.
Comment 29 Li Yuan 2007-08-09 06:49:07 UTC
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?
Comment 30 Li Yuan 2007-08-09 07:13:34 UTC
Hi Michael,

cc-ing you to another bug :)
Do you know the history of why we don't implement accessibility on gtksocket/plug?
Comment 31 Michael Meeks 2007-08-09 08:34:48 UTC
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.
Comment 32 Li Yuan 2007-08-09 09:58:38 UTC
(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 :-)

Comment 33 Willie Walker 2007-11-01 15:08:59 UTC
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.
Comment 34 John Covici 2008-05-05 21:53:34 UTC
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?
Comment 35 Rich Burridge 2008-06-03 16:27:29 UTC
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).