A few cases weren't properly handled, while a few others simply weren't called by the top-level script. This PR seeks to make the top-level clean action able to fully clean all built components, perhaps save for sample and test pages.
Test-bot: skip
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.
