chore(web): quality pass for locked-flick resetting may be needed

[jahorton]

Test Results

(From #11129)

• TEST_GESTURE_REGRESSIONS (FAILED): Tested with the attached PR build (Keyman 17.0.296-beta-test-11129) on an Android (13) Mobile device and here is my observation: 1. Tested the baseline tests on the "Test unminified KeymanWeb" test page on the Chrome browser and noticed that some tests like Test_Numeric_From_Shift, Test_Modipress_Multitap_Flick_Preview and Test_Flick_during_Modipress are failed due to a lack of motion in animation while dragging the specified key by up-and-right motion or sometimes with straight up or down motion.

I have attached a video file (test_flick_during_modipress) represents there is a lack of motion in the animation and it does not show the expected output Úq on the text input screen.

modipressmultitap.mp4

Originally posted by @bharanidharanj in #11129 (comment)

[jahorton]

It's quite possible that the best way forward, from a user-testing perspective, is to develop a different testing keyboard that specifies 90-degree offset flicks, rather than 45-degree neighboring ones. Flick-locking should operate more intuitively in such cases.

[mcdurdin]

@jahorton I am not sure what to do with this -- is there specific work that you see that we should do apart from changing the keyboard?

I have not yet assigned this to you or this sprint; is this work that we need to complete before release?

[jahorton]

@jahorton I am not sure what to do with this -- is there specific work that you see that we should do apart from changing the keyboard?

I have not yet assigned this to you or this sprint; is this work that we need to complete before release?

We can probably get by without doing this before release; I think it's more a "user testing stability" issue than anything else.

[jahorton]

Also... I think the prospective sil_ipa variant I put together might work well as a test keyboard for this. Its flick pattern matches the pattern I was thinking of, now that I'm thinking about it.