bug: keyboard caching does not differentiate between desktop and mobile

[sentry-io]

Sentry Issue: KEYMANWEB-COM-1VT

TypeError: null is not an object (evaluating 'this.getElem().parentNode')
  at None (/keyboard/japanese/1.0.1/japanese-1.0.1.js:192:21)
  at None (/keyboard/japanese/1.0.1/japanese-1.0.1.js:104:27)
  at _KeyboardInterface.process (https://s.keyman.com/kmw/engine/17.0.334/src/common/web/keyboard-processor/src/text/kbdInterface.ts:1078:19)
  at _KeyboardProcessor.processKeystroke (https://s.keyman.com/kmw/engine/17.0.334/src/common/web/keyboard-processor/src/text/keyboardProcessor.ts:225:46)
  at _InputProcessor._processKeyEvent (https://s.keyman.com/kmw/engine/17.0.334/src/common/web/input-processor/src/text/inputProcessor.ts:194:47)
...
(11 additional frame(s) were not displayed)

[sentry-io]

Sentry Issue: KEYMANWEB-COM-1VV

[jahorton]

For both these Sentry events, the underlying cause is that keyboards not targeting mobile-web, such as the CJK keyboards (and japanese in particular), will be made available on mobile-web due to the current caching scheme. This should not be the case for such keyboards due to lack of support.

These errors are related and surface because the japanese keyboard assumes that it will have successfully inserted its picker elements into the page's hierarchy and be able to look them up later by ID. The picker insertion only occurs in the Web engine's "desktop" mode - and not on touch devices. Since the picker elements never get inserted when in "mobile" mode, any search for the element returns a null.

[jahorton]

One approach would be to detect which form-factor a user is utilizing and target keyboards supporting that. Granted, this is likely available only client side, so we may need to link in both versions of the cache, only calling the "correct" method once the Web engine's device-detection processes have completed determining the user's form-factor. (This could be done by await keyman.init or similar mechanism.