bug(web): dropped chars and unintended upflicks with 17.0.307-beta

[mcdurdin]

Regression from 17.0.301-beta.

Video on drive: https://drive.google.com/file/d/1AWCRAX1eT6Ql9TRycP2c3U36k5LbTqOY/view?usp=drivesdk

[alex-larkin]

I observe the same behavior using Keyman Beta for Android 10.0.307-beta and my own keyboard. I have "Show taps" activated on my device (Samsung Galaxy S21 running Android 12) helping to confirm the issue:

https://drive.google.com/file/d/1vb5A0XvwKIHn72ww38XSLotKl9fgwSQk/view?usp=sharing
(Sorry for the many sincere typos not related to the issue 😂. Had to type quickly.)

Not in recording:

Observed no dropped characters when typing slowly.

I tried to reproduce the issue on the keyboard I installed from my KAB app (using the same .kmp file) but found that the issue was not present there.

[mcdurdin]

17.0.304 is good

[mcdurdin]

17.0.305 is good

[mcdurdin]

17.0.306 is good. Regression definitely introduced in 17.0.307-beta.

[jahorton]

The most likely influence would be #11216, then. And I do recall seeing cases when rapid-typing that a longpress in the middle of rapid-typing sometimes cancelled out further keystrokes; I should've documented it at the time. (I noticed this while addressing the previous rapid-typing issue.) Given #10647, if a longpress were accidentally triggered when rapidly typing, and then the prior bug triggered, that could easily cause dropped keystrokes.

Gives me something to look at and chase down, at least.

[jahorton]

Device used in the initial error report: Samsung Galaxy A53 5G

• Usually used in portrait
• Official resolution spec: 1080 x 2400 pixels, ~405ppi.

[jahorton]

I think I found one repro, at least:

Type the following sequence with the pattern described below: alskdjfhg (the full second row, starting from opposite ends)

1. Press and hold 'a'
2. Press and hold 'l'
3. Release 'a'
4. Press and hold 's'
5. Release 's'
6. Continue the pattern, only releasing a key after the next key in the sequence has been pressed and held.

Of course, also make sure you don't take long enough for a longpress to trigger.

Expected result: obviously, alskdjfhg
Actual result: asdfg (or similar).

• In other words, if executed perfectly, every other key will be dropped.

[mcdurdin]

That repro correlates well with what I'd expect when typing rapidly.

[jahorton]

I believe I've now identified why it showed up with .307.

In #11216, the "resolution priority" of the base longpress model was raised significantly in order to ensure that the longpress up-flick wasn't blocked by flick-start for keys with both longpresses and downflicks. This new priority is also significantly higher than that of a basic 'initial-tap'.

This has an unfortunate side-effect in which a missing flag from the longpress model had a cross-effect with certain longpress cancellation patterns. If a second touch starts during the longpress wait, we cancel the longpress. Unfortunately, the flag that said "the second touch isn't part of the longpress" wasn't present... meaning that failure of the longpress also auto-cancelled the touch and input of the cancelling touch.

[mcdurdin]

Glad you were about to figure this out @jahorton!