PR #13860 fixed a similar error by adding a check for NaN. However, it
missed doing it for `layoutWidth` and only changed `layoutHeight`. This
PR adds a similar check to `layoutWidth` and will thus fix the error
we're still seeing in Sentry.
The same error could potentially happen in `internalHeight`, so we
add the check for NaN there as well. Addresses code review comments.
Also add unit tests for all three methods.
# User Testing
TEST_INUKTITUT_KEYBOARD: Using Keyman for Android, install the
`inuktitut_pirurvik` and verify that no error notifications appear.
Fixes: #14108
Fixes: [KEYMAN-WEB-RA](https://keyman.sentry.io/issues/6579536471/?referrer=github_integration)
Cherry-pick-of: #14684
Fixes: #13908
Fixes: KEYMAN-WEB-RK
Cherry-pick-of: #13959
Fun fact: `Number('')` returns 0, not NaN! I thought it would do the latter in #13838, which is what led to the issue this PR addresses.
Fixes: #13766
Fixes: KEYMAN-WEB-QX
It seems that at some point, Developer has been compiling raw "12" values in the touch-layout JSON as a numeric 12 for the fontsize field. This clearly happened for the inuktitut_pirurvik keyboard; we should also inspect urdu_phonetic, which has the same raw "12".
This change ensures that Web can handle this case without spewing tons of warning/error messages. It also adds error-logging to help with diagnosis for any related issue in the future.
Previously logging an error resulted in two Sentry issues to be created.
This change now combines the log message and the error into one call to
`console.error`, thus resulting in only one Sentry issue being created.
Fixes: #13644
The banner should also double-check the height of its suggestions, applying downscaling where needed to ensure the suggestions' text does not flow out of bounds. Additionally, if the main keyboard body's keys required downscaling due to text height, this will likely also result in similar scaling for the suggestions.
When a keyboard's layout specifies font-upscaling, that scaling should also be applied to the banner. This was not previously being done, which could lead to font-size discrepancies between the two (as noted with `khmer_angkor` in the base issue).
Addresses, but does not fix, #13588.
This change provides a simple classname to the page-trailer element Keyman Engine for Web adds to pages when in mobile mode. This "page trailer" was originally added so that the on-screen keyboard does not hide important elements near the bottom of the page when visible. That said, we have gotten site-designer complaints about it; exposing a way for site-designers to retrieve it in queries and/or customize its properties will provide a reasonable workaround for such cases.
Fixes: #13620
Turns out there was actually a final-row pixel offset being applied for the OSK. I _believe_ this was something originally done for touch-oriented OSKs that ended up applied to all during 17.0's OSK refactoring efforts.
kmwosk.css does define layer-group padding above and below (1 px each) for touch keyboards already. Furthermore, things look fine when removing this extra 1px offset on the bottom from the last row. I think we're fine to just drop this minor offset and move on for now.
As identified in the analysis for #13344, held backspaces have not been cancelled when receiving new inputs. It's better and cleaner to have it act similarly to normal keystrokes - receiving a new key input autocompletes any currently-held output keys.
The current, existing behavior also has the potential to get particularly messy with multitaps, which restore the context at their start. If a backspace is held and then a multitap begins, each new tap of the multitap would undo the backspaces that triggered since the first tap of the multitap.
To facilitate debugging cases where gestures don't work as intended, this adds sanitized logging for keystrokes resulting for gestures. These are only to be output when a relevant error or warning is emitted.
This is primarily being added to facilitate investigation of #13344.
Fixes: #13278
The fallback default keyboard corresponding to an uninitialized cookie is `Keyboard_us:en`. This should only occur if the site actually registers its stub before initialization - and we weren't checking/filtering for this properly.
The error itself only occurred if there _were_ stubs pre-registered before init - if none existed, the error does not result.
