Fixes#6455.
This involved adding an extra hint to the data passed into the lexical
model layer, being the CasingForm that the current layer wants to use.
Given there are several entry points to the lexical model layer, this
meant a few places where we needed to check the current layer.
I refactored the very long function `InputProcessor.processKeyEvent` to
extract out the `buildAlternates` function. There should be no
functional changes to the `buildAlternates` code. But it makes
`processKeyEvent` significantly easier to read.
Fixes#6489.
The issue arose in multitap scenarios, where the tip display state
became desynchronised with the actual display state as maintained in
the Android code.
The fix I applied was to reduce some of the state checks into the js
wrapper android-host.js. This is not ideal. The state machine for key
tip display is scattered across four functions in three files:
* visualKeyboard.ts: VisualKeyboard.highlightKey
* visualKeyboard.ts: VisualKeyboard.showKeyTip
* embedded/keytip.ts: KeyTip.show
* android-host.js: oskShowKeyPreview / oskClearKeyPreview
I have moved the actual re-creation check for the tip to the lowest
level functions -- those in android-host.js. But a more detailed look at
the state machine and a refactoring would certainly be worthwhile.
Fixes#6455.
This involved adding an extra hint to the data passed into the lexical
model layer, being the CasingForm that the current layer wants to use.
Given there are several entry points to the lexical model layer, this
meant a few places where we needed to check the current layer.
I refactored the very long function `InputProcessor.processKeyEvent` to
extract out the `buildAlternates` function. There should be no
functional changes to the `buildAlternates` code. But it makes
`processKeyEvent` significantly easier to read.
This is a follow-up for #6331. We still did not have enough detail to
be able to trace the root cause of the load errors. This adds a little
more diagnostics.
While this was done in code as a global override, probably following
Apple stylistic changes, it is better to leave this to the keyboard
developer to decide on.
Adjusts the dimensions to use pixel boundaries to prevent antialiasing
for some of the key preview and longpress popups, and adjusts horizontal
positioning of key preview to center more precisely, for iOS.
Observed while debugging another issue on iOS. The
VisualKeyboard.waitForFonts function sets up a busy timer to wait for
font loading. This functionality is not even needed on the iOS app,
because it's really only used for the touch alias elements.
However, it was being called, potentially multiple times, leading to the
timer never being removed. On Android, the timer was correctly removed.
This aligns the iOS code path with the Android code path.
Fixes#5942.
The touch alias element position was not consistent across all browsers,
leading to misalignment in some situations. Identified missing CSS to
make the positioning consistent, as far as I can tell, which led to the
additional benefit of reducing the per-browser special cases.
Fixes the following crash noted when testing on keymanweb.com, focusing
during the load process on a slow network.
```
helpers.ts:111 Uncaught TypeError: Cannot read properties of null (reading 'vkbd')
at g.pageFocusHandler (keymanweb.ts:125:44)
at sentryWrapped (helpers.ts:87:17)
```
Fixes#5929.
Fixes#6381.
This fixes four separate issues with the longpress popups and key
previews:
1. The key preview was offset by a couple of pixels (unreported issue).
2. The background 'shim' did not cover the key caps, which caused them
to look startlingly white when the rest of the background greyed
down (#5929).
3. The popup menu was incorrectly wrapping to two rows due to sizing
model mismatches (#6381).
4. The popup menu would be realigned incorrectly for the in-app
keyboard, when moving it to keep it in the keyboard area (#5929).
Fixes#6364.
Removes `&layerChanged` and adds `&newLayer` and `&oldLayer` system
stores with the additional nuances around values as described in #6364.
When embedding the On Screen Keyboard into a page, the calculation for
the bounding rectangle only took into account the first offsetParent,
which meant it would get the offset incorrect when there were multiple
layers of offsetParents.
Once I changed to using getAbsoluteX / getAbsoluteY, this also corrects
for scroll with window.pageOffsetY, so we can eliminate that special
case for fixed positioning.
This was observable in the Web Developer test window, where interaction
with the bottom row of the keyboard in touch mode was not working
correctly, in 15.0.210-beta.
