bug(web): desktop OSK fails to load, with error, if keyboards are added before init() is called

Keyman 17.0 has added support for a more "streamlined" approach to loading keyboards and their OSKs, but there's one small detail causing it not to work properly on 'desktop' form-factor devices.

History:

This was of particular note for our mobile platforms, as this allows their keyboards to load more smoothly and responsively. A side effect of this work, and of #11505 in particular, is that KeymanWeb almost fully supports keyman.addKeyboard() calls before keyman.init() now. Almost. It turns out that there's one small wrinkle remaining, though.

This issue was brought to us via this Community site post: https://community.software.sil.org/t/experimenting-with-add-keymanweb-to-a-website-add-custom-keyboard-to-a-website/8829

You see, the user is actually using the pattern that we almost fully support now, but it turns out that there was a catch. The order of operations for loading the desktop OSK is not intuitive because of #11174 - the OSK will actually start loading the keyboard before the FloatingOSKView has fully initialized! In particular, this.titleBar will be undefined in postKeyboardAdjustments(), throwing an error as a result.

https://github.com/keymanapp/keyman/blob/13700e4a9f11fde9624203c002690a5fefa02da6/web/src/engine/osk/src/views/floatingOskView.ts#L121-L126

I was able to find a single Sentry error report that can be linked to this: https://keyman.sentry.io/share/issue/aab9d42e86b84a9cb8a10358aa27d5dd/ Interestingly, it looks to be from user testing, rather than a standard public use... but it does make sense. Our current uses within Keyman Developer's web-server setup, within keymanweb.com, etc all rely on the keyman.init() Promise setup, which avoids the issue.

Current Keyman versions: 17.0.326, 18.0.55.

keymanapp / keyman

bug(web): desktop OSK fails to load, with error, if keyboards are added before init() is called #11785