Bug 5972 – Race condition with hardware shift key

Bug 5972 - (int-145043) Race condition with hardware shift key

(int-145043)
Summary:	Race condition with hardware shift key

Status:	VERIFIED FIXED

Product:	Desktop platform
Component:	Input method framework
Version:	5.0/(1.2009.42-11)
Platform:	N900 Maemo

Importance:	Low normal (vote)
Target Milestone:	5.0/(2.2009.51-1)
Assigned To:	Joaquim Rocha
QA Contact:	input-method-framework-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2009-11-01 01:04 UTC by Ryan Abel
Modified:	2010-01-14 12:28 UTC (History)
CC List:	4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description Ryan Abel (reporter) maemo.org

2009-11-01 01:04:24 UTC

SOFTWARE VERSION:
1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:

1. Open an application that accepts text input.
2. Press shift.
3. Quickly press two or more characters.

EXPECTED OUTCOME:
Only one shifted character appears from one press of the shift key.

ACTUAL OUTCOME:
I've been able to get up to 5 shifted characters to appear from one press of
the shift key.

REPRODUCIBILITY:
Sometimes, depending on CPU load and character entry speed.

OTHER COMMENTS:
This makes rapid text entry rather obnoxious since you end up with a lot of
extra shifted characters.

User-Agent:       Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2a1pre)
Gecko/20090928 Firefox/3.5 Maemo Browser 1.4.1.15 RX-51 N900

Comment 1 Lucas Maneos 2009-11-01 13:02:31 UTC

It seems (xev is no help here) to happen when a key is pressed before any of
the previous ones is released.  Example (mostly ignoring effects of autorepeat
for simplicity, some finger gymnastics required):

1. Press and release Shift.
2. Press and hold Z (Z is entered).
3. Press and hold X (X is entered). 
4. Press and hold V (V is entered).
5. Release Z or X (autorepeat produces "v" characters).

A second key press should trigger the shift state reset, instead of waiting for
a key release.

Comment 2 Faheem Pervez maemo.org

2009-11-01 14:01:50 UTC

(In reply to comment #1)
> It seems (xev is no help here) to happen when a key is pressed before any of

Here's a xev that works under Fremantle: http://qwerty12.qole.org/xev

(Diff here: http://qwerty12.qole.org/xev.diff)

Comment 3 Lucas Maneos 2009-11-01 14:31:13 UTC

(In reply to comment #2)
> Here's a xev that works under Fremantle: http://qwerty12.qole.org/xev
> 
> (Diff here: http://qwerty12.qole.org/xev.diff)

Thanks! Of course now I realize that it doesn't help anyway as it grabs the
input before him sees it...

But, why isn't this already in bugzilla?  Do file a bug with the patch, you
know you want to ;-)

Comment 4 Faheem Pervez maemo.org

2009-11-01 18:20:02 UTC

(In reply to comment #3)
> 
> But, why isn't this already in bugzilla?  Do file a bug with the patch, you
> know you want to ;-)
> 

Done: #5987

Comment 5 Andre Klapper maemo.org

2009-11-11 15:10:03 UTC

This has been fixed in package
hildon-input-method-framework 1:2.1.40-1+0m5
which is part of the internal build version
2009.46-7
(Note that 2009 is the year and the number after is the week.)

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

Comment 6 Ryan Abel (reporter) maemo.org

2010-01-02 03:33:39 UTC

*** Bug 7548 has been marked as a duplicate of this bug. ***

Comment 7 Andre Klapper maemo.org

2010-01-14 12:28:54 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.