Sticky Keys not released after mouse action.

[dotancohen]

The accessibility option Sticky Keys in it's default state releases the 'stuck' modifier key after any HID input (mouse click, keyboard non-modifier button pressed). Additionally, Sticky Keys has a Lock feature which does not automatically release the 'stuck modifier', but rather waits until the user presses the modifier key again to release it.

In Kubuntu 13.10 the 'Lock' feature is broken. It is _always_enabled_ for the mouse, and _always_disabled_ for the keyboard, regardless of whether or not the checkbox is checked. Actually, Kubuntu 13.04 had this problem as well, but I though that it was a configuration issue on my part and simply avoided updating to 13.04. However, I can no longer avoid updating and I cannot use current Kubuntu with the Accessibility issue in this state.

What are the conditions for considering an issue high priority? Users with Accessibility issues can no longer use the current KDE, does that quality for high priority?

Steps to Reproduce:
1. Enable Sticky Keys (System Settings -> Accessibility -> Modifier Keys)
2. Enable "Use sticky keys" and disable "Lock sticky keys".
3. In Kate, click Ctrl then click a mail in the Message List Pane to select it. Now click on a second mail and notice that it too is selected. Now a third.
Actual Results: All the mails are added to the selection.
Expected Results: One would expect that with the "Lock sticky keys" checkbox disabled that the Ctrl button would be released after clicking a single mail. With "Lock sticky keys" disabled the expected workflow to select multiple mails is to either press the Ctrl button after each mail or to hold it down.

Note that this issue affects all modifier keys in all applications. This is most annoying when using Shift- or Ctrl- MouseScroll i.e. in Firefox as the modifier is not release when expected.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: systemsettings 4:4.10.5-0ubuntu0.1
ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8
Uname: Linux 3.8.0-31-generic x86_64
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
Date: Mon Oct 28 22:13:10 2013
InstallationDate: Installed on 2013-05-01 (180 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: True
SourcePackage: kde-workspace
UpgradeStatus: No upgrade log present (probably fresh install)
---
.tmp.unity.support.test.0:

ApportVersion: 2.12.7-0ubuntu6
Architecture: amd64
CasperVersion: 1.336ubuntu1
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
DistUpgraded: Fresh install
DistroCodename: trusty
DistroRelease: Ubuntu 14.04
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993] (prog-if 00 [VGA controller])
   Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993]
LiveMediaBuild: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140108)
MachineType: Gigabyte Technology Co., Ltd. To be filled by O.E.M.
MarkForUpload: True
Package: xorg-server (not installed)
ProcKernelCmdLine: file=/cdrom/preseed/username.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity
ProcVersionSignature: Ubuntu 3.12.0-7.15-generic 3.12.4
Tags: trusty ubuntu regression reproducible compiz-0.9
Uname: Linux 3.12.0-7-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 09/24/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F2
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: F2A55M-HD2
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF2:bd09/24/2012:svnGigabyteTechnologyCo.,Ltd.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnF2A55M-HD2:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To be filled by O.E.M.
dmi.product.version: To be filled by O.E.M.
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.50-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.0.1-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.0.1-1ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.14.5-1ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu10
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.907-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu1
xserver.bootTime: Wed Jan 8 16:29:02 2014
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.14.5-1ubuntu2

[dotancohen (dotancohen)]

Note that I had suspected this to be a KDE issue, but the KDE folks insist that nothing relevant has changed in their software:
https://bugs.kde.org/show_bug.cgi?id=325893

[Harald Sitter (apachelogger)]

There weren't any changes and you get exactly the same behavior on Ubuntu.

Question is just whether it is X that changed behavior or if perhaps some distro patch does.

[Harald Sitter (apachelogger)]

Definitely a XKB issue. It applies to Kubuntu, Ubuntu, Arch and Gentoo at the very least. Also making distro level patching very unlikely. Unless those three Xs have the same silly patch ;)

[Rob Rosenbaum (robnormal)]

FWIW, I have this same bug in Debian wheezy, with XFCE.

[Libreoffice-org (libreoffice-org)]

The accessibility option Sticky Keys in it's default state releases the 'stuck' modifier key after any HID input (mouse click, keyboard non-modifier button pressed). Additionally, Sticky Keys has a Lock feature which does not automatically release the 'stuck modifier', but rather waits until the user presses the modifier key again to release it.

In recent XKB releases on all popular Linux distros (since about the beginning of year 2013) the 'Lock' feature is broken. It is _always_enabled_ for the mouse, and _always_disabled_ for the keyboard, regardless of whether or not the configuration option is enabled.

What are the conditions for considering an issue high priority? Users with Accessibility issues can no longer use the current Linux distros, does that quality for high priority? I'm still stuck on Kubuntu 12.10 due to this issue as I have a manual disability.

Steps to Reproduce:

1. Enable Sticky Keys (In KDE: System Settings -> Accessibility -> Modifier Keys ; In Gnome: Settings -> Accessibility -> Some tab with keyboard/typing)

2. Enable "Use sticky keys" and disable "Lock sticky keys".

Now test:
In Kmail, click Ctrl then click a mail in the Message List Pane to select it. Now click on a second mail and notice that it too is selected. Now a third.
Actual Results: All the mails are added to the selection.
Expected Results: One would expect that with the "Lock sticky keys" checkbox disabled that the Ctrl button would be released after clicking a single mail. With "Lock sticky keys" disabled the expected workflow to select multiple mails is to either press the Ctrl button after each mail or to hold it down.

Note that this issue affects all modifier keys in all applications. This is most annoying when using Shift- or Ctrl- MouseScroll i.e. in Firefox as the modifier is not release when expected. This is also a serious accessibility issue for disabled users (such as myself).

[dotancohen (dotancohen)]

Upstream bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=73155

Harald, Rob, please comment on that bug to confirm the issue and its severity for disabled users. (K)ubutnu 12.10 will soon no longer be viable and disabled users will not have a supportable upgrade path.

[zBrain (nick-customdesigns)]

Confirming this bug as well as it's severity and high level of importance to disabled users.

It causes all sorts of unexpected behaviour - just imagine your control or shift keys being pressed when you aren't expecting it. Virtual desktops flipping, emails deleted instead of moved to trash are but 2 of many issues.

It's most notable in my text editor. Shift click to highlight text, then ctrl+c (which is now shift+ctrl+c as shift was not released by the mouse click as expected) then ctrl+v and it pastes the wrong thing because the copy operation didn't do what was expected.

This bug apparently affects all disabled users across all DEs. As mentioned, some users are forced to remain on old and soon to be unsupported versions in order to avoid the problem.

[Alan Coopersmith (alan-coopersmith)]

You've filed this bug against the XKB configuration data files - i.e. the ones
with all the different keyboard layouts for all the different international
keyboards in different locales. While there are some configuration data for
sticky keys in these files, it hasn't changed in years:
http://cgit.freedesktop.org/xkeyboard-config/log/compat/accessx

Are you sure this bug is in the configuration data and not the X server or
the input (evdev) driver?

Helping narrow down which package is responsible and which versions work
or don't work will greatly help in finding where the bug is to get it fixed.

[Libreoffice-org (libreoffice-org)]

@Alan:

Thank you, I had intended to file with XKB but it doesn't show on the list, so I filed in the closest place that I could find. For reference, here is the list:
https://bugs.freedesktop.org/enter_bug.cgi

If you know of a better place, I would love to get it in there.

[Alan Coopersmith (alan-coopersmith)]

(In reply to comment #3)
> Thank you, I had intended to file with XKB but it doesn't show on the list,

Because XKB is not a single piece of software - it's a protocol, data files,
a bunch of utilities, support in various other programs, etc. Most of the
XKB software is found in bugzilla under the "Xorg" product.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #0)
> In Kmail, click Ctrl then click a mail in the Message List Pane to select
> it. Now click on a second mail and notice that it too is selected. Now a
> third.
> Actual Results: All the mails are added to the selection.
> Expected Results: One would expect that with the "Lock sticky keys" checkbox
> disabled that the Ctrl button would be released after clicking a single
> mail. With "Lock sticky keys" disabled the expected workflow to select
> multiple mails is to either press the Ctrl button after each mail or to hold
> it down.

I don't think that's the intended behaviour. Looking at the protocol description at http://www.x.org/docs/XKB/XKBproto.pdf it says "Modifiers are automatically unlatched when the user presses a non-modifier key.". Buttons are not keys in X, so going by just this I'd say that it works as intended. Are you saying that this used to work differently, and if so what server version is the latest you know of working?

[penalvch (penalvch)]

dotancohen, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xorg-server REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[dotancohen (dotancohen)]

apport information

[penalvch (penalvch)]

dotancohen, as per http://www.gigabyte.us/products/product-page.aspx?pid=4374#bios an update is available for your BIOS (F4). If you update to this following https://help.ubuntu.com/community/BiosUpdate , does it change anything? If it doesn't, could you please both specify what happened, and just provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful.

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Thank you for your understanding.

[dotancohen (dotancohen)]

I'll not update the BIOS on this machine for unrelated reasons. For one thing, this is obviously not a BIOS issue, so I suspect that comment #28 was an automated reply and not a real attempt at resolving this issue.

Additionally, I can verify the issue on all six computers that I've tested on (home computer, work computer, mother-in-law's computer, a neighbour who uses Kubuntu, and two co-workers who use Kubuntu and Ubuntu). These are all different systems. Furthermore, Rob Rosenbaum has confirmed the issue in this bug and others have confirmed the issue in other forums.

[Libreoffice-org (libreoffice-org)]

> Looking at the protocol description at http://www.x.org/docs/XKB/XKBproto.pdf
> it says "Modifiers are automatically unlatched when the user presses a
> non-modifier key.". Buttons are not keys in X, so going by just this I'd say
> that it works as intended. Are you saying that this used to work differently,
> and if so what server version is the latest you know of working?

Yes, up until Xorg 1.13.0 inclusive it worked differently. In those systems and action with the mouse would also release the sticky keys. In all other systems (Windows, Mac OSX) sticky keys is also released after the first mouse action.

Releasing sticky keys on the first mouse action is definitely the way users expect sticky keys to work, and the way that it had worked until recently. Remember, these are disabled users and cannot easily change their work habits to accommodate this disruptive change. I am one of them :) and simply cannot use a system with the new behaviour.

This is from a Kubuntu 12.10 machine which _works as expected_:

$ X -version

X.Org X Server 1.13.0
Release Date: 2012-09-05
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-37-generic x86_64 Ubuntu
Current Operating System: Linux bruno 3.5.0-44-generic #67-Ubuntu SMP Tue Nov 12 19:36:14 UTC 2013 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-44-generic root=UUID=d817f86c-cf93-4736-89c8-65a8a4ee4f85 ro quiet splash vt.handoff=7
Build Date: 16 October 2013 04:38:15PM
xorg-server 2:1.13.0-0ubuntu6.4 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.26.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.

Kubuntu 13.04 suffers from this bug (which is the reason that I cannot upgrade), according to distrowatch.com that system uses Xorg 1.13.3. Additionally, I just tested in the latest dev release of Ubuntu 14.04 with Xorg 1.14.5 and it also suffers from this bug. Thus, the change was made in one of the following Xorg versions:
1.13.1
1.13.2
1.13.3

Thank you for looking into this issue.

[Peter Hutterer (peter-hutterer)]

bisected to this commit:

commit 11319a922575f1da1d3c5774728c0dee12bab069
Author: Peter Hutterer <email address hidden>
Date: Thu Oct 11 16:03:33 2012 +1000

    xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP

[Libreoffice-org (libreoffice-org)]

Thank you for finding the relevant commit, Peter!

Is there any progress in resolving the issue? The latest popular Linux distros which do not suffer from this regression are all scheduled for depreciation soon.

Thank you!

[Libreoffice-org (libreoffice-org)]

Is there any schedule for resolving this? Myself and other disabled users rely on Sticky Keys and at least I personally cannot use a system that demonstrates this bug. That means that I am currently using older, unsupported Linux distros and I will soon have to find an alternative operating system.

I understand that the change was made to resolve a different issue, but the bug introduced is severe enough that certain disabled users can not use any operating system that suffers from this issue. You can image my concern at the prospect of having to use an alternative OS and possibly upsetting my entire workflow (and the applications that I use) just because of this issue.

As Linus says, old bugs are better than new bugs. Please consider a fix or reverting the change.

[intherye (intherye)]

This issue also exists in Xubuntu 13.10

[Andres G. Aragoneses (knocte)]

In case you didn't know, this bug has hit slashdot.

The only useful comment there, though, seems to be this one: http://linux.slashdot.org/comments.pl?sid=4959535&cid=46607985 (which seems to reply to comment#5, so I'll quote it:

"I do know that even as a non-disabled user, the behavior Peter describes as "per spec" (that is, mouse buttons are not keys for the purposes of releasing the sticky keys) is counter-intuitive since the modifier keys interact with mouse buttons the same way they do with non-modifier keys (ie. Control modifies selection with mouse clicks the same way it modifies selection with the keyboard). Given that normal interaction with both non-modifier keys and mouse buttons, I'd expect instructions about how modifier keys behave to also apply analogously when both non-modifier keys and mouse buttons (but not mouse movements) are involved. Either that or I would expect modifier keys to not interact with mouse clicks the same way they do with regular keys."

HTH

[Doug Tentilhao (pacman7de)]

Is this what introduced the 'bug` and if so wouldn't it be trivial to revert, except maybe the old behaviour was wrong. Is there any other option to configure sticky-keys+keyboard+mouse events to the satisfaction of the original poster.

http://cgit.freedesktop.org/xorg/xserver/commit/?id=2decff6393a44b56d80d53570718f95354fde454

[zBrain (nick-customdesigns)]

No, it is not posible to configure around the bug. This is not a 'bug', but a bug. There is no question the current implementation is not working as it should.

Part of the issue here seems to be the spec, and the want to follow it. The spec unfortunately is either poorly worded or written wrong. The honest truth of the matter is it needs to be fixed, and then we can hopefully move past that.

The sentence "Modifiers are automatically unlatched when the user presses a non-modifier key." in the spec needs to read to the effect of:

"Modifiers are automatically unlatched when the user performs an action which is affected by the modifier, unless the lock option is selected."

The bottom line here is the current functionality is broken for the group of people it is intented to help, and that is a fundamental flaw.

[penalvch (penalvch)]

dotancohen, as a WORKAROUND when 12.10 EOLs, you could use Precise with the quantal enablement stack as outlined in https://wiki.ubuntu.com/Kernel/LTSEnablementStack .

[Peter Hutterer (peter-hutterer)]

fwiw, that commit linked above broke the behaviour but merely reverting it will break the thing that commit fixed in the first place. When I looked at it fixing this properly was more complicated than I hoped and I've since been busy with other stuff. I'm not claiming that the spec is correct and the one and only solution. if we had one behaviour for years that is often (not always) a better indicator what we should do than what the spec says.

and since it has been on slashdot: please refrain from commenting unless you have something useful to contribute to this bug and how it could be fixed. if you're affected and/or want this fixed, add yourself to the CC list, don't comment here. If you are outraged, tell it to your friends and neighbours, don't comment here. Too many comments muddy the water and make it harder to follow what's going on, which again makes it less likely this will get fixed.

[Peter Hutterer (peter-hutterer)]

http://patchwork.freedesktop.org/patch/23451/

[dotancohen (dotancohen)]

Is it too late to get this fix into the 14.04 LTS release? I hate to see an LTS release without this critical accessibility fix. In fact, it is only because the previous LTS release (12.04) had proper accessibility that I was able to revert to that version when this issue cropped up.

If an LTS release gets out the door without this accessibility fix, any other accessibility issues that crop up in any of the next few Ubuntu versions will be absolute showstoppers. Telling people to "Just use that latest LTS release until your issue is resolved" won't be valid due to accessibility issues in the LTS version itself!

Is it reasonable to expect that accessibility issues would be a priority in an LTS release?

[Peter Hutterer (peter-hutterer)]

commit 98924719d524bf87cdf301063cd744d1271c33ff
Author: Peter Hutterer <email address hidden>
Date: Wed Apr 2 13:55:10 2014 +1000

    Revert "xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP"

[Libreoffice-org (libreoffice-org)]

Thank you Peter, I look forward to triaging this change.

Have a terrific week! Your contributions to Xorg and to the the systems that we depend upon are very much appreciated!

[zBrain (nick-customdesigns)]

This change has hit Debian Testing, and is such a relief I had to come back and say thanks again for the fix!

[dotancohen (dotancohen)]

I am concerned that Xorg 1.16 has not made it into 14.10 yet. Can this be prioritized? The current 14.04 LTS version does not contain the fix, therefore disabled users are still on 12.04.

[Paul White (paulw2u)]

Comment #51 suggests fixed in Ubuntu 14.10 or maybe 15.04 so closing as fixed.