Keyboard drops characters if I type too fast

[GoogleCodeExporter]

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

Original issue reported on code.google.com by des.siam...@gmail.com on 8 Jul 2011 at 7:26

[GoogleCodeExporter]

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.

Original comment by peterwri...@isky.co.za on 24 Jul 2011 at 10:34

[GoogleCodeExporter]

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?

Original comment by Klaus.We...@gmail.com on 27 Jul 2011 at 1:27

• Changed state: Accepted

[GoogleCodeExporter]

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

Original comment by des.siam...@gmail.com on 27 Jul 2011 at 2:05

[GoogleCodeExporter]

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

Original comment by peterwri...@isky.co.za on 27 Jul 2011 at 12:40

[GoogleCodeExporter]

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

Original comment by Klaus.We...@gmail.com on 9 Oct 2011 at 2:07

[GoogleCodeExporter]

Yes.  Very much so and very irritating.

Original comment by pwri...@virgon.co.za on 9 Oct 2011 at 8:19

[GoogleCodeExporter]

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.ap
k

Original comment by Klaus.We...@gmail.com on 10 Oct 2011 at 5:30

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 16 Oct 2011 at 3:35

[GoogleCodeExporter]

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! 

Original comment by des.siam...@gmail.com on 16 Oct 2011 at 4:13

[GoogleCodeExporter]

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

Original comment by Klaus.We...@gmail.com on 16 Oct 2011 at 7:23

• Changed state: FixInTest

[GoogleCodeExporter]

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

Original comment by Klaus.We...@gmail.com on 13 Jan 2012 at 9:29

• Changed state: Fixed

[GoogleCodeExporter]

Excellent, thank you very much!

Original comment by peterwri...@isky.co.za on 16 Jan 2012 at 7:22

[GoogleCodeExporter]

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]

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