GNOME Bugzilla – Bug 668213
a11y-keyboard manager writes to GSettings on login
Last modified: 2012-06-25 12:43:46 UTC
The act of logging in to GNOME causes g-s-d to write a whole lot of stuff to GSettings. This seems to happen from a function called set_gsettings_from_server in gsd-a11y-keyboard-manager.c. GSettings should only be written to as a result of explicit user action. It is definitely inappropriate to be storing transient information like this in it.
On inspection, it appears that this schema is accessed by gnome-settings-daemon, gnome-control-center and gnome-shell (for the a11y icon). It does not appear to be accessed by applications or ATs. It's obvious that the shell and gnome-control-center have legit reasons for writing to these keys, but I can't imagine the settings daemon has any useful reason at all.
Okay. This code is useful for when the 'turn on accessibility features from the keyboard' feature is turned on and you do one of the special keystrokes (like holding down shift for 8 seconds) to enable the feature. When this happens, the X server sends us a XkbControlsNotify. It seems that we get XkbControlsNotify when one of these things has not happened, though. In fact, we seem to get it when we setup the initial config for ourselves... So now we have 3 options: 1) Say that these keyboard-enabled accessibility modes are transient for the duration of the session and go back to the UI-selected settings at next login 2) Reduce the severity of this problem by only running this function if the 'turn on from keyboard' option is set (which it is not, by default). 3) Figure out a way to filter out the XkbControlsNotify messages that don't come in response to direct user input.
unmentioned 4) do the sane thing and move the policy choices about enabling/disabling a11y settings out of the X server and into g-s-d...
Created attachment 205588 [details] [review] a11y-keyboard: only update GSettings on user input X sends a message to us to tell us when the accessx settings are changed. They can change for two reasons: because a client (like ourselves) has changed them or because the user did some keystroke (like pressing shift 5 times to enable stickykeys). We want to update GSettings in response to user requests, but prevent spurious updates caused by the X server notifying us of the updates that we just did for ourselves, so check that the update is actually caused by user input.
Review of attachment 205588 [details] [review]: Makes sense to me, fwiw
Review of attachment 205588 [details] [review]: Looks good to me. Add to 3.2 if appropriate too.
Attachment 205588 [details] pushed as 5e4dcfb - a11y-keyboard: only update GSettings on user input
Pushed to gnome-3-2 as well.
This fix isn't quite correct. The server sets event_type for control notifies that are in direct reaction to a key event. SlowKeys is handled by a timer, and thus the event_type is always 0. So with this commit we don't see the warning about slow keys turning on. Suggested fix: Expand the ctrls.event_type check to also check if the slow keys have changed. If so, then notify the user regardless. if ((xkbEv->ctrls.changedControls & XkbControlsEnabledMask && xkbEv->ctrls.enabledControlChanges & XbkSlowKeysMask) || (xkbEv->ctrls.event_type != 0)) ....
Is there any way we could fix the X server to be more reasonable about this? Even though slowkeys are based on a timer, it's a timer that's firing based on a particular keystroke... There really ought to be some concrete way to tell the difference.
http://patchwork.freedesktop.org/patch/10795/
Thanks so much Peter. I was really not looking forward to having kludge this in GNOME, so this is great.