feat(web): gesture-selection 🐵

[jahorton]

The new MatcherSelector class facilitates proper update synchronization among all GestureMatchers that share one or more common GestureSources and ensures that if more than one match completes successfully at the same time, the highest priority one wins and is selected as the "correct" gesture component model for this "stage" of the ongoing gesture.

@keymanapp-test-bot skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

Test Artifacts

• Android
  • Keyman for Android apk
  • FirstVoices for Android 16.0 apk
  • FirstVoices Keyboards for Android apk
  • KeyboardHarness apk
  • Keyman for Android 16.0 apk
  • KMSample1 apk
  • KMSample2 apk
• Developer
  • Keyman Developer - build failure
  • Compiler Regression Tests - build failure
  • kmcomp.zip - build failure
• iOS
  • Keyman for iOS (simulator image)
  • FirstVoices Keyboards for iOS (simulator image)
  • TestFlight internal PR build version - 17.0.174 (0.9407.9243)
• Keyboards
  • Test Keyboards - build failure
• Web
  • KeymanWeb Test Home
• Windows
  • Keyman for Windows - build failure
  • FirstVoices Keyboards for Windows - build failure
  • Text Editor (32 bit) - build failure
  • Text Editor (64 bit) - build failure

[mcdurdin]

LGTM I guess? It's pretty abstract at this point so hard to know really what it's all doing without the entire model of it in my mind. So I've just looked at the code, lots of comments which is good, nothing obviously messy.

I don't know how this will perform?

[mcdurdin]

I'm not sure why this is needed for this module when none of our other mocha-based unit tests need it?

[jahorton]

Until now, I've generally been running the mocha tests from the command-line and placing breakpoints when debugging is necessary. I've actually avoided setting up any launch.json configurations within VS Code until now. Breakpoints from main-project code seem to activate more consistently during TS-spec'd tests for me when I launch them through a launch.json configuration than when I run them via console. I'd been having trouble with that when validating recent code changes... since I started writing tests for these newer parts of the gesture engine in TS rather than plain JS.

This file exists to facilitate launch.json debugging configurations, ensuring that it refers to the "correct" tsconfig.json file when using ts-node. As gesture-recognizer needs to target ES5, but its tests don't, things go funky during TS-test loading should the ES5 config (the one in the project's root folder, thus most likely to be treated as "default") be picked.

[jahorton]

Huh. Revisited this after noting the main comment of #9453 (review):

I don't really understand the big picture gestures use case as the mechanical unit test of correctness doesn't really explain why the gestures design would need such a thing.

I did have a vacation since then, so I figured the refresher might help. Turns out... the unit tests actually pass now with this disabled!

I think I see what happened now:

keyman/common/web/gesture-recognizer/src/engine/headless/gestures/matchers/matcherSelector.ts

Lines 138 to 146 in d03cd7f

	/*
	* Easiest way to ensure resolution priorities are respected: keep 'em sorted in descending order.
	* When we iterate through on update-steps, we go sequentially; the first Promise to be marked
	* 'resolved' wins.
	*/
	this.potentialMatchers.sort((a, b) => b.model.resolutionPriority - a.model.resolutionPriority);
	// Now that all GestureMatchers are built, reset ALL of our sync-update-check hooks.
	this.resetSourceHooks();

I'd been having some serious issues getting certain multitap scenarios to work correctly, largely due to the timing by which source-subview updates were being processed and how that related to the processsing of path-termination.

Lines 145-146 above were part of the last additions to this PR - additions that fixed some "fun" underlying problems with update timings. Ensuring that updates were processed in the correct order probably fixed the same issues that were previously undermining resolutionPriority ordering - for some gesture types, path updates can trigger resolution of their corresponding gesture matcher, after all.

So... we might actually able able to straight-up drop the Promise prioritizer thing after all. At least it did help lead me to the true underlying cause for the issues I'd been using it to address.

[jahorton]

And now... fully dropped.