#53 Keyboard drops characters if I type too fast

[Anonymous]

Originally created by: des.siam...@gmail.com

What steps will reproduce the problem?
1. Start any application, go to a text field
2. Type something, using only your thumbs, as fast as you can
3. Note that if you press two letters extremely quickly, both keys highlight one after the other, but only the second letter gets inserted

What is the expected output? What do you see instead?
I expect both letters to be inserted in the order I pressed them (so, key-down order).  Instead, characters get consistently dropped, and more characters get dropped as my typing speed increases.

What version of the product are you using? On what operating system?
Hacker's Keyboard v1.20
Samsung Galaxy Tab 10.1, Android 3.1

Please provide any additional information below.

I'm fairly sure this is not user error, because I have experimented with the stock Android keyboard and the Samsung keyboard, and neither has this problem.

I don't believe this is related to multi-touch, because I experimented with (slowly) pressing one key, then pressing another, then releasing both -- and that worked as expected (both characters got inserted in the correct order).  It may be that the keyboard expects each letter to be held down a certain minimum length of time, and when I type too fast I'm just not holding the keys down long enough.

If that is the case, it would be great to have an option to configure this behavior.  Since I mostly type with my thumbs, I don't really have the problem of "ghost" keystrokes where I accidentally brush over letters I didn't intend to type.

Please let me know if there is something I can do to help with this.  (Typing on a soft keyboard is tedious enough already; having to slow down so the software can keep up is even more tedious. :) )

[Anonymous]

Originally posted by: peterwri...@isky.co.za

I have the same issue. It often happens when typing "ght" really quickly, as well as when I type my name "Peter" the second "e" get left out, i.e., I get a "Petr".

I can confirm the behaviour, the key is hihlighted (you see?) but the lettr does not appear.

Other than this, the best keyboard out thee... t h e r e. Am also willing to help in anyway.

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

I can't reproduce this, does this happen consistently for you? Are you both using the Galaxy Tab? I don't think there's supposed to be a minimum pressed time, but it's possible that this is hidden in the underlying Gingerbread code I hadn't modified.

Are you sure you're fully lifting the finger off the screen so that it's not treating the two adjacent presses as a drag?

Do you have "popup on keypress" switched on, or vibrate / sound on keypress? What are your completion settings?

Can you find any pattern about which keys or sequences are affected by this?

Status: Accepted

[Anonymous]

Originally posted by: des.siam...@gmail.com

Yes, it happens consistently, mostly with keys located near each other -- most commonly I have this problem with 'T' and 'H' (e.g "there", "that", "the", etc.) or 'N' and 'G' ("thing").  I tried again just now and could not reproduce with keys that were more than one or two spaces apart.

It only ever happens when I'm using two different fingers for each key press -- perhaps you're right and it's interpreting the two presses so close together as a drag.  Indeed, when I deliberately drag my finger across adjacent keys, I get the same behavior.

"Popup on keypress" is off.  "Vibrate" is on, "sound" is off.

It might just be user error -- the stock Android keyboard (on the Galaxy Tab at least), exhibits the same behavior when I intentionally drag between keys.  However, the keys are much bigger and there is a larger gap between them, so I imagine it's less likely I would accidentally trigger a drag when typing adjacent letters.

If you can do something to mitigate it, though, that would be awesome. :)

[Anonymous]

Originally posted by: peterwri...@isky.co.za

This is has been happening to me in landscape mode, just tested in portrait, also happening there.

Agreed, also only when two keys are next to each other. 
Agreed, also in Samsung keyboard and Standard Android, although in these the keys are NOT highlighted if they are pressed to quickly.

Tried alternating two keys really quickly, if there is a gap between them, f and h, both letters appear as I type, if g and h, nothing appears until I slow down a bit, and then one of the letters appears every now and then. 

I can have nothing appear on the screen for 5 or 10 seconds. 

When I am doing this the key is highlighted, so the software is recognising the touch.  As above, this behaviuor is not the same as the Samsung or Standard keyboards.

Happens with keys on different rows, for example. 5-r alternated, or 4-r alternated.

Does not happen if the keys are adjacent for example 4-t or 5-e.

Happens with alternating keys if another finger is on the shift key, GHGHGHGH does not appear, FHFHFHFHF does appear.

On a normal keyboard I often take advantage of different finger lengths to type quickly, for example, "re" or "oi" is typed with the first two fingers of my right hand, at the same time.  On the tablet, it is interpreted as "e" or "i".

Does not happen when I am pushing the outside of the adjacent keys, rather than the centre of the middle.

Hacker's Keyboard not sure of version, downloaded it last week.
Samsung Galaxy Tab 10.1 (GT-7510), Android 3.1

Settings :
Keyboard height, portrait: 25 percent
Keyboard height, landscape: 35 percent
Full Keyboard in portrait mode: Use full 5 row keyboard (checked)
Suggestions in landscape mode: Hide suggestions in landscape mode (unchecked)
Landscape mode editor override: Always use Standard view (checked)
Labeled (sic) alternate keys: Non-letter keys only
Key label scaling: 50 percent
ConnectBot tab key mode: Enable compatibility workaround (checked)
Vibrate on keypress: (unchecked)
Sound on keypress: (unchecked)
Popup on keypress: (unchecked)
Touch to correct words: (checked)
Auto-captilization: (unchecked)
SHow setting key: always hide
Voice input: Mic on main keyboard
Input languages: Slide finger on spacebar to change language
Quick fixes: (unchecked)
Auto-complete: greyed out - (unchecked)

Hope it helps

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Sorry, I haven't made any progress tracking this down so far. Is it still happening in current versions?

[Anonymous]

Originally posted by: pwri...@virgon.co.za

Yes.  Very much so and very irritating.

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Thanks for confirming, I'll see what I can do. There's some rather obscure code in LatinKeyboardBaseView and PointerTracker related to touch input that I don't really understand, and it may need a few tests to figure out what's going on. I'm suspecting that this is a side effect of the OS low-level touch screen event reporting interacting badly with the keyboard's heuristics on some systems.

For starters, want to try this experimental version, where I've turned off swipe disambiguation? Note that this may break sliding the space bar to switch languages. http://hackerskeyboard.googlecode.com/files/hackerskeyboard-v1026-experiment1.apk

Status: Started

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

I've made more radical changes, and added a new settings option for "Sliding key events". Turning that on causes the keyboard to send key events for (non-modifier) keys that you slide across.

Can you please try this version, and let me know if that setting improves things for you?
  http://code.google.com/p/hackerskeyboard/downloads/detail?name=hackerskeyboard-v1026-experiment3.apk

Since you said that you see the keys light up, my theory is that your tablet reports closely-spaced touch events as movement instead of as separate touch events - I can't reproduce this properly, but if this what's happening this should make it work better.

[Anonymous]

Originally posted by: des.siam...@gmail.com

So I'm trying this out right now while typing this comment, and it does seem to help with certain letter combinations, like "gh", but with others (like "ut", where the U and T are separated by the Y, or "TH" which is separated by G), all the letters in the middle get inserted as well, which isn't optimal.  Perhaps you could just insert the letters at the start and end of the drag?  That seems like it might be a better compromise.

On balance, though, it's definitely an improvement.  Thanks for looking into this!

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Thanks for testing, I think this confirms that it's caused by the touchscreen reporting move instead of tap events. I agree that first&last key probably makes more sense than sending all the intermediates too, though I may just make it a selectable option for those who want to type "red" by swiping.

New version soonish, I need to clean up some of the hacks involved first.

(To pre-empt any related questions, I'm still not planning to add any word-guessing style swipe input.)

Status: FixInTest

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

[Bulk bug update] The new Market release 1.29 includes the changes from the v1.28 prerelease series, and these "FixInTest" issues should now be fixed. If not, please reopen the bug with additional information. If the original bug covered multiple separate issues that aren't all addressed, please open new bug(s) for the leftover ones.

Status: Fixed

[Anonymous]

Originally posted by: peterwri...@isky.co.za

Excellent, thank you very much!

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

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.)

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

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

Status: Verified