This fixes a deployment problem which seems have been around since 17.0.
We also have to deploy the `web/build/publish` folder which contains all
the files necessary to load and run the test keyboards.
The fix can only be tested after a release build has happened and the
files have been deployed.
Fixes: #14234
Cherry-pick-of: #14237
Build-bot: skip
Test-bot: skip
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.
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.
