The parameters for `setKeyboardForControl` basically have three
different modes:
- an id of a keyboard/language to set that keyboard, enabling independent
keyboard mode
- empty string to set the system keyboard, enabling independent keyboard
mode
- `null` to disable independent keyboard mode.
Our previous code didn't properly handle the last two modes. This change
fixes the problems and also clarifies and updates the documentation.
Also included is an improvement to the guide-examples e2e tests that now
wait until all keyboards are loaded (which may fix#16167).
Partially drafted by kilo.ai.
Fixes: #16080
Build-bot: skip release:web
Previously the browser component and web engine had the same error message
which made it harder to know where the exception happened if a call stack
or source map were missing. This change modifies the message in engine.
Related-to: $#16190
Build-bot: skip release:android,ios,web
Test-bot: skip
KeymanWeb has long had `keyman.build` and `keyman.version`. Neither of
these properties expose the full version string, and consumers are
forced to manipulate them to get a partial version string.
This change deprecates both these properties, and introduces a new
`keyman.versionInfo` property, which returns an object with all the
version information, most importantly `full`.
Update documentation and add a unit test for this, following the unit
test pattern established throughout Keyman of a unit test filename
matching the implementation class. The `KeymanEngineBase` class is a
little difficult to instantiate so this unit test module currently has
a minimal instantiation which provides enough to fulfill the one
included test.
Test-bot: skip
Fixes: #16335
The new unit tests here caught the behavior addressed by this PR's predecessor, #16349.
Meanwhile, a _different_ behavior was noted here that had added complexity - it so happens the test case I constructed managed to catch a bug in backspace handling! Fortunately, a small tweak was able to resolve the issue.
Build-bot: skip build:web
Test-bot: skip
Build-bot: skip release:web release:android
Relates-to: #16254
Relates-to: #16313
Noting that similar issues to those fixed by #16313 have occurred in other gesture-related contexts, it seems wise to implement the same sort of fix for all gesture types - perhaps the Android WebView has its own circumstances where similar "reference replacements" may occur and throw off our internal key-matching logic.
Fixes: #16254
While I have not been able to find a definitive online reference, it appears that the key-spec instance attached to OSK elements may be replaced within the iOS Safari-based WebView despite no re-assignment existing within Keyman Engine for Web code.
The references should not change under any condition, but it appears that something external within the iOS WebView causes this anyway. Fortunately, we can still check against the unique element ID, which provides a way around this issue.
Build-bot: skip release:web release:ios
`currentKeyboardSrcTextStore` can return `null` if the global
`textStore` should be used. This change reflects this in the return
type.
Build-bot: skip build:web
Test-bot: skip
