chore(web): improve error logging in predictive-text worker message validation
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.
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.
Addresses a PR comment by mcdurdin on #13597 (at https://github.com/keymanapp/keyman/pull/13597#discussion_r2023971170) in regard to the motivation for gesture input serialization.
> I just don't understand how the problem described here can arise -- unless we are introducing deferral with promises -- but even then, if we consistently defer every incoming event with a promise, then the order would still be automatically enforced.
In particular, this aims to clarify how the macrotask queue gets involved and can interfere with the ordering of promises.
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.
