Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shift causes next number to be entered as shift+number #24

Closed
GoogleCodeExporter opened this issue Apr 11, 2015 · 12 comments
Closed

Shift causes next number to be entered as shift+number #24

GoogleCodeExporter opened this issue Apr 11, 2015 · 12 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Enter text in a text-entry field, such as in the (Google) "Search" app, the 
location bar of the browser, or ConnectBot's public key passphrase entry field.

2. Try typing a mixed-case word, such as "Pa55word". Use one finger. Press: 
[shift] p a 5 5 w o r d

3. The shift turns off after the "p" is entered as "P", and "a" is lowercase as 
expected. However, the first "5" becomes "%".


What is the expected output? What do you see instead?

Expected: Pa55word
Resulting: Pa%5word


What version of the product are you using? On what operating system?

Hacker's Keyboard v.1.13, on CyanogenMod 7.0.3, on Nook Color.


Please provide any additional information below.

Not all text entry fields do this. For instance, Jota Text Editor doesn't, nor 
do some text entry fields in web forms. Nearly all password entry fields do, 
however.

Original issue reported on code.google.com by TylerTol...@gmail.com on 2 Jun 2011 at 11:00

@GoogleCodeExporter
Copy link
Author

I've experienced this problem as well.  I didn't see the post until after I 
made one myself.  I'd just like to confirm that it occurs on my Motorola Droid 
X2, running 2.2.2 (Froyo).

Original comment by kaishi.a...@gmail.com on 3 Jun 2011 at 4:35

@GoogleCodeExporter
Copy link
Author

I can reproduce it on my phone and am investigating - sorry about that, but 
it's unfortunately tricky since shift key handling is split among multiple 
classes with no clear separation of duties. (I may not have tackled this 
alternate keyboard if I'd known ahead of time that this would be so fragile...)

It's not happening in the emulator, so I'm guessing it's related to multitouch 
capable devices?

Original comment by Klaus.We...@gmail.com on 4 Jun 2011 at 5:18

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Issue 25 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 4 Jun 2011 at 5:19

@GoogleCodeExporter
Copy link
Author

Progress, I think I found the issue, and it's arguably in the Android 
framework, not the keyboard app:

- InputMethodService's sendKeyChar() has odd special handling for digit keys, 
apparently using a built-in keymap to handle shifted characters at the OS 
level: 
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java
/android/inputmethodservice/InputMethodService.java#l1827

- for reasons I don't fully understand, the input handler is treating the 
sequence SHIFT down, SHIFT up as some kind of sticky shift state. Maybe a 
leftover from hardware keyboard handling?

Anyway, what got me on the right track was that the German keyboard produced a 
"&" on the 7 key due to this bug, while my keymap has a "/" in that location.

I've got a workaround which turned out to be fairly complicated, but I think 
I'm able to preserve the ability to use shifted arrow and other special keys 
without triggering the framework bug. Release soon, once I've cleaned up the 
debugging code I added while tracking this down.

Original comment by Klaus.We...@gmail.com on 4 Jun 2011 at 7:14

@GoogleCodeExporter
Copy link
Author

Fantastic, Klaus. Thanks for the rapid response. I've got a rooted device, so I 
can test any beta apk's for you.

Original comment by TylerTol...@gmail.com on 4 Jun 2011 at 9:58

@GoogleCodeExporter
Copy link
Author

This issue was closed by revision a1e772c1aa38.

Original comment by klausw@google.com on 4 Jun 2011 at 7:52

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Please try v1.14rc3 (or later) which should fix it: 
http://code.google.com/p/hackerskeyboard/downloads/list

BTW, rooting should not be necessary for trying the prereleases, you just need 
to permit non-Market installs in your application settings. AFAIK only some 
AT&T phones have this locked down and require rooting (or "adb install" via 
USB?) as a workaround.

Original comment by Klaus.We...@gmail.com on 4 Jun 2011 at 11:25

@GoogleCodeExporter
Copy link
Author

Fantastic, again! That solved the problem.

Original comment by TylerTol...@gmail.com on 5 Jun 2011 at 7:16

@GoogleCodeExporter
Copy link
Author

I have not attempted this fix yet but I appreciate the quick turn-around and 
excellent communication.  I'm looking forward to assisting with testing in the 
future :)

When can we expect this update to be on the market?

Original comment by kaishi.a...@gmail.com on 6 Jun 2011 at 3:23

@GoogleCodeExporter
Copy link
Author

It's very easy to install from the Downloads link, Kaishi. Just enable 
non-market installs. It worked for me immediately.

Original comment by TylerTol...@gmail.com on 6 Jun 2011 at 3:47

@GoogleCodeExporter
Copy link
Author

Bulk update - changing "Fixed" to "Verified" for old bugs.

(Background: I'm changing the "Fixed" status to be considered open, the next 
steps in the lifecycle will be the closed states "FixInTest" and "Verified". 
This lets me mark issues as "Fixed" in commit messages without hiding them from 
the issue tracker.)

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:33

@GoogleCodeExporter
Copy link
Author

Bulk update - changing "Fixed" to "Verified" for old bugs.

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:34

  • Changed state: Verified

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant