GNOME Bugzilla – Bug 104058
CursorLocate 'AnyModifier' grab clashes with other accessibility features
Last modified: 2015-11-03 18:08:47 UTC
The gnome-settings-daemon 'locate cursor' feature is very useful for accessibility and for any situation in which cursor visibility is less than ideal (for instance, a glare-filled environment, etc.). However the default locate-cursor key, "Control-left", is grabbed with the AnyModifier flag in XGrabKey. This grab is held for the duration of the user's session, and it prevents other clients from successfully issuing an 'AnyKey' grab against any set of modifiers. Unfortunately, though we don't encourage use of 'AnyKey' grabs, they are sometimes necessary at least temporarily for accessibility, and at-spi clients do issue them. If the cursor-locate feature is on, then the at-spi calls fail and the assistive technologies may be left nonfunctional. I don't see that the AnyModifier mask is really necessary in the locate-pointer case, I suggest that using only the null mask (i.e. no modifiers) and the LockMask would suffice. I attach a patch which makes the necessary change. Jonathan, can we get this in for 2.2? I really hoped to target 2.2 as an "assistive technology compatible" release.
Bill, you forgot to attach the patch :)
nope; just lost my connection to cvs.gnome.org... here's the patch.
Created attachment 13723 [details] [review] replaces AnyModifier grab for locate-cursor with a no-modifier and a lock-modifier grab.
Seems viable. Please commit
Thanks Jody! I have been playing with this patch and though it solves the first problem (failing keygrabs), there's a remaining issue with the way Owen did the key event handling in the GdkFilterFn 'function'. It seems to break "interlocking grabs", that is, if you press and hold the Control key, clients holding some Control-modifier grab won't get notified unless you press the sequence twice. I need to talk to Owen about solutions for that; probably a small tweak to the existing patch. However I don't think such tweaks will invalidate the need for the current patch's delta.
I think I'd better chat with Owen first before committing this patch. I think there are issues with the way the keygrab is being done, and it's not clear that LocatePointer keyed to the control key can actually be made compatible with other passive keygrabs that use the Control modifier (since the XAllowEvents call with ReplayKeyboard ignores pending passive grabs from higher up in the window hierarchy).
on reflection I think the patch is appropriate. I am not sure the secondary problem (conflict with Control-modifier passive grabs) is solvable without changing the behavior of the locate-cursor feature. Still worth a chat with Owen. I will commit the existing patch. thanks again Jody!.
Can this bug be closed now, Bill?
Andrew, Jody, thanks a whole lot for accepting the patch. Unfortunately it's only a partial fix, it solves the worst problem but not the root issue. maybe we should close this bug - but only if another one is opened with almost the same summary :-(. It turns out that although the patch fixes some symptoms, the end result is still that AT clients cannot use Control-sequence global keybindings when the locate cursor feature is turned on. Actually this isn't really specific to AT, no client can successfully get XGrabKey grabs with a modifier of "Control" if this feature is turned on. That's because the grab on the control key itself takes precedence, and because the locate cursor feature holds the grab until the next event, it means that when XAllowEvents is called with 'ReplayKeyboard' the events are passed to X windows without being processed by any other pending passive keygrabs. Do you follow? Yuck.. This is a cool feature but I can't see any way of keeping it from breaking control-key keybindings without altering the current behavior. Any ideas, Owen?
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Calum, I assume still present/relevant in gnome 2.6 with gtk 2.4?
I am unaware of any changes which could have improved this.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
I suggest you raise the version then.
*** Bug 319995 has been marked as a duplicate of this bug. ***
The behavior of Alt-Tab is also strange and may be related to this bug. If a client is registered for at-spi keyboard events and Alt-Tab is pressed, the client only receives the Alt press. The tab press, the Tab release, and the Alt release are all consumed by the desktop. This is also true of other desktop hotkeys like Alt-F1. Shouldn't at least the Alt release be allowed to pass to clients? If not, an AT will think Alt is still being held when it isn't.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Under Wayland, the feature as it is implemented in gnome-settings-daemon will not work at all. To be implemented under Wayland, it will need to be implemented in gnome-shell: https://bugzilla.gnome.org/show_bug.cgi?id=690055 Any bugs or new features for "Locate pointer" should be fixed in a new implementation in gnome-shell.