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).
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.
