fix(web): proper handling of key previews, longpresses near-synchronous with layer change 🐵#9803
Conversation
User Test ResultsTest specification and instructions
Test Artifacts
|
…/web/state-change-source-rewrite
common/web/gesture-recognizer/src/engine/headless/touchpointCoordinator.ts
Outdated
Show resolved
Hide resolved
|
I wonder if the errors I fixed in #9893 might be the related to the second test's failure; it does help recover from some 'stuck' scenarios. As for the first... I can't seem to find any Sentry error reports for that error. Weird. I did manage to get a couple of stuck-highlighting states when attempting a repro on my personal iPhone, though, so maybe I can get something from that. ... and nope - doesn't show anything for iOS either. And the WebView within the mobile app isn't set as inspectable. Looks like I may have to do a local build to investigate that angle further. |
…/web/state-change-source-rewrite
|
@keymanapp-test-bot retest all @bharanidharanj I've merged in a PR that may fix related details; could you try again, please? |
@jahorton Sure, I will do it. |
|
OK, good. I had a suspicion that the last test, at least, would be fixed by that. Not completely surprised about the first, since we can't seem to get specific error reports out, and it could be a cross-effect. |
|
OK, finally got something out of testing a local build with iOS, once I remembered to rebuild the dependencies (common/web/types, web's build:app/webview). Fortunately... that's a check I've since disabled later in the main PR chain, with no noticeable ill-effects from doing so. Will push a fix on that shortly. |
| if(baseContact.isPathComplete) { | ||
| throw new Error("GestureMatcher may not be built against already-completed contact points"); | ||
| } |
There was a problem hiding this comment.
To be clear, this was never in place due to errors that occurred elsewhere; this was enforcing an early assumption about how the system should work. I've since realized that said assumption is safe to relax.
|
... and yep, no more errors after rebuilding when testing that change, at least on the local iPhone. All gesture-engine unit tests pass locally, too. @keymanapp-test-bot retest TEST_LAYER_MASH |






This PR ensures that key highlighting and subkey menus can be properly triggered for keys pressed near-simultaneously with others... even after said 'others' have triggered a layer change.
Warning: might need a 🧼🚿 after this one. The solution works, but it's not super-pretty.
From #9802:
This is based on #9802. Given the concerns and complications noted there, we need to actively rewrite the path for sources that trigger a state change for a previously-existing gesture sequence (when not becoming part of it) so that KeymanWeb knows the correct layer even before it's time to emit a key. In fact... it's best if it's "immediately" available to KMW.
Basically, this PR "bumps up" when correct information is accessible... in part by deliberately delaying the event that provides the new
GestureSourceto KeymanWeb. There's also the matter of the rewrite itself, but that's comparatively simpler. The key detail is that the rewrite itself needs the delay, as we shouldn't perform the rewrite if it does .User Testing
TEST_LAYER_MASH: Using the Android Keyman app and the default keyboard (SIL EuroLatin)...
TEST_SENTENCE_START: Using the Android Keyman app and the default keyboard (SIL EuroLatin)...
Wand a right-hand finger over the capitalT.WTorTW, FAIL this test.WtorTw.Re: step 5 - yes, touching simultaneously is hard. That's why the repetitions - you'll near-certainly get it right at least one of the ten tries. (And certainly close enough to repro the error in
16.0-stable.)