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.
The Caps Lock change I made in the previous commit broke
desktop Caps Lock handling. The fix was a little more
convoluted. Turns out that _UpdateVKShift is also pretty
crufty. I simplified it, removing dead code.
Fixes#5964.
It seems that the test for subkey position was incorrect when the
document had been scrolled. Removing the test for `fixed` positioning
resolves the issue.
This fixes an issue that arises when loading the Keyman Developer Server
home page and there are registered keyboards, but no keyboards active.
The floating osk view would throw an exception because it would attempt
to set the title of the view from the active keyboard, which is `null`.
Selection direction was not maintained in mutations, which could have
unexpected consequences. Added support for selection direction to input
and textarea.
The functions `getTextBeforeCaret()` and `getTextAfterCaret()` are named
somewhat incorrectly, as they actually get the text before and after the
active selection (and a collapsed zero-length selection is equivalent to
the caret). It would be worth renaming these in a future refactor.
This PR fixes the unit tests so that caret position is tested correctly
with an active selection -- the caret can be at either the start or the
end of the selection, corresponding with the direction in which the user
originally selected the text. It also fixes the assumptions around the
above named functions for `input` and `textarea` types.
Note that selection interactions are still buggy with prediction
selections; these bugs were present in 15.0.118-alpha and I will tackle
them in an upcoming commit.
Relates to #5853 and others.
Selection management was not working properly with the various
OutputTargets:
1. When there is a non-empty selection, rules have no context -- it's
like new text.
2. Backspace over a selection deletes just the selection.
3. Typing a character replaces the selection, of course, and collapses
the caret to the end of the new text.
4. `hasSelection` is a very strange name for `OutputTarget` descendants.
It doesn't mean "has an active selection" but rather, kinda means
"supports selection internally".
5. Added `isSelectionEmpty` which is used for some of the new selection
rules above.
Note that the `touchAlias` OutputTarget class does not currently support
selection. I hope we can deprecate `touchAlias` with the use of
`inputMode` (#3030) in the future, rather than adding support for
selection.
Relates to #5853.
Two things happened here:
1. Construction of Mocks made an assumption that the selection should
always be deleted (outputTarget.ts:363). However, for NewContext and
PostKeystroke processes, we don't want to change anything.
2. Even if nothing is changed, the transcription would emit what is
in theory a no-op ruleTransform (insert="", deleteLeft=0,
deleteRight=0). But apps would treat this as deleting the selection.
This fix goes a little broader than I would have preferred, but adds a
readonly mode to the transcription and mock model, so that we can
control explicitly when changes are applied to the text store.
If the OSK had a non-integer width or height stored in the OSK cookie,
then the width and height would be parsed incorrectly and the OSK would
fail to be sized correctly on first load; this also caused a script
error and made the OSK impossible to interact with.
