GNOME Bugzilla – Bug 99505
locked-screen dialog is inaccessible to Gnopernicus and GOK
Last modified: 2012-03-07 09:36:55 UTC
Issue: ------ The locked-screen password dialog in 'xscreensaver' cannot be read through the Gnopernicus screen reader in an accessible desktop. Test Case: ---------- 1. Change the following fields in your .xscreensaver file: timeout: 0:00:10 lock: True lockTimeout: 0:00:00 This runs the screensaver AND locks the screen after 10 seconds. The xscreensaver daemon picks up these changed preferences. 2. Start brlmonitor on <machine_A>, xhosted to <machine_B> 3. Start gnopernicus on <machine_A> 4. The Braille Monitor is currently reporting focus on a widget. The screensaver kicks in after 10 seconds. Braille Monitor reports "No focus" Mouse or keyboard actions do NOT present changes in Braille Monitor. 5. Press the Return button, and enter text in the password dialog. Notice that Braille Monitor, again, reports only "No focus". 6. Press the Return button, and enter the correct password to unlock. Braille Monitor updates to the previously focused widget.
Well, the problem is that this dialog is showed using X functions directly, so it has no accesibility layer that gnopernicus or GOK (as said on bug #108005) can access. This is a real stoper for a accesible desktop. Possible workarounds: a) Disable xscreensaver when running gnopernicus/GOK b) Disable lockmode when running gnopernicus/GOK c) Just write a patch to xscreensaver to use a gtk standar dialog for asking password. (That can be a compile time option like --use-gtk-for-ulockdialog) What do you think about this?
Of the three possibilities, the third certainly seems the most reasonable. However there is another part to the issue - since xscreensaver's lock feature disallows posting of other applications' windows and disallows access to the keyboard and mouse, assistive technologies are likely to be "locked out" until the lock dialog unposts. For instance a GOK (Gnome Onscreen Keyboard) user would not be able to respond to the lock dialog since GOK would not, as it now stands, be allowed to post its graphical virtual keyboard and probably would not be allowed to receive input device events which the screen lock is active either. Similar problems are likely to be faced by gnopernicus - since I expect the screen lock dialog does a keyboard and mouse grab.
Ok, so if we want an accessible xscreensaver we need to hack on it. We can add some window properties to GOK and gnopernicus like __ASSISTIVE_WINDOW and then allow xscreensaver to show these windows and allow also them to receive input events. This, plus gtk+ dialog will be a huge patch, and I'm not sure if could be integrated into mainstream xscreensaver.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
we're looking at this (Brian C. and myself) now. It seems we should: (1) use the gtk+ lock dialog (where is that patch anyhow?) (2) make the keyboard and mouse grabs optional, since they aren't needed as long as the lock dialog maintains keyboard focus while posted (the grabs offer almost no true security, they only serve to 'hold focus') (3) modify metacity to allow certain kinds of windows to post above override-redirect windows #1 should allow us to get appropriate ATK info from the lock dialog, and allow gnopernicus and gok to query the lock dialog UI and speak/braille the text (note that the password field would not echo the entered characters via speech or braille, same as for sighted users) #2 would allow GOK to receive input (so that it could synthesize keysrokes) and also allow the user to interact with gnopernicus controls. We'd of course need to confirm that neither app was able to circumvent the "lock dialog foreground" behavior, but I don't think gnopernicus or gok would be able to interact with a non-foreground application successfully, i.e. I think this would not be a problem but it needs to be confirmed. #3 would be required for GOK and/or the magnifier window to be viewable when the lock dialog is posted. In the case of the gnopernicus magnifier in fullscreen mode, perhaps we should only lock the 'target' screen used by the GNOME session, and not lock the magnified view (since by definition it would only magnify what was on the 'primary' screen). [note: internally to the magnifier we call such a 'target' screen, i.e. the one applications are drawing on, the 'source' and we call the magnified view the 'target', in contrast to the way I just used the term]. However in any case we'd need to allow GOK to post above or alongside the lock dialog. Note that the main GOK window doesn't take focus, so it doesn't need to be focusable, just visible/"raise-able".
*** Bug 134945 has been marked as a duplicate of this bug. ***
*** Bug 135339 has been marked as a duplicate of this bug. ***
*** Bug 144094 has been marked as a duplicate of this bug. ***
*** Bug 149720 has been marked as a duplicate of this bug. ***
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
For what it's worth, I recently wrote up a document explaining why these things are probably a lot harder to make work than you think: http://www.jwz.org/xscreensaver/toolkits.html
so the best choice now is using gnome-screensaver I guess.
yes, though I expect gnome-screensaver will require some work in order to make it reasonably accessible with gnopernicus and gok. For one thing, gnome-screensaver will need to be 'LoginHelper'-aware, so that it can raise specific requested windows from (trusted) assistive technologies. Ideally you'd check the exec path of a program that requested a window to be raised during screen lock, to make sure it's from a suitably-secure directory, i.e. only root-writable. There are of course some security implications for just about any kind of accessibility enhancements, care is needed :-)
BTW the 'LoginHelper' interface I mentioned above is part of at-spi, assistive technologies implement it so that login/authentication agents of various kinds can cooperate with ATs.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
According to its developer, xscreensaver is not under active development anymore. It is unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping - Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.