- Also renamed `prefixed` and `withoutPrefix` functions to use the name
that was aliased on most cases: `toPrefixedKeyboardId` and
`toUnprefixedKeyboardId`.
- Renamed `ModelManager` class to `ModelCache` which was the name used
everywhere except in comments.
Part-of: #15292
Test-bot: skip
Addresses review feedback from Marc and Darcy:
- Add JavaDoc comments to getKeyboardHeightMin() and getKeyboardHeightMax()
explaining the purpose, parameters, and return values
- Implement separate pending height tracking per keyboard type (in-app/system)
and orientation (portrait/landscape) instead of a single flag
- Add four preference keys following KMKey_ naming convention:
KMKey_PendingHeightUpdate_InappPortrait, KMKey_PendingHeightUpdate_InappLandscape,
KMKey_PendingHeightUpdate_SystemPortrait, KMKey_PendingHeightUpdate_SystemLandscape
- Create helper function getPendingHeightKey() to determine the correct key
- Create setPendingHeightUpdate() and getAndClearPendingHeightUpdate() functions
- Fix applyKeyboardHeight() to use new helper functions and remove broken
heightApplied variable and duplicate pending height logic
- Update KMKeyboard.onResume() to use getAndClearPendingHeightUpdate()
- Add documentation links for getKeyboardHeightMin and getKeyboardHeightMax
in index.md
Handling invalid orientations
updating orientation logic
refresh webview height if ApplyKeyboardHeight() has been applied without KB active
I ran into a bug building this code into app-builders and fixed it downstream. This commit pushes it upstream.
While resize dialog is open:
- Keyboard WebView is NOT loaded (isKeyboardLoaded() == false)
- ACTION_UP saves to SharedPreferences: ✅ Works
-But skips WebView layout update: ❌ Because keyboard not loaded
- User exits dialog, keyboard appears:
- If the keyboard WebView loads and reads from SharedPreferences properly: ✅ Works
- But if there's a timing issue or the WebView had old layout params cached: ❌ Touch zone mismatch
sentry-manager is used by Keyman Engine for Android and Keyman Engine
for iOS, but not directly by KeymanWeb, nor does it have any
dependencies on /web. So it does not make sense to keep it under /web.
es-bundling is used by sentry-manager and potentially other /common/web
tools in the future, so moving it under /common/tools makes it more
consistent in the future.
This is part of simplifying the web source tree; these changes do not
make significant build performance differences at this time.
Test-bot: skip
