Fixes#7227.
We want to use keyman.com for now even for alpha builds, as
keyman-staging.com is going to be used for transition to Docker-based
hosting, and it will be problematic to try and share that process with
alpha builds.
Fixes up scripts (except under /linux) to use `#!/usr/bin/env bash`
instead of `#!/bin/bash` or `#!/bin/sh` so that we don't end up with
the ancient version of bash supplied with macOS.
This became urgent with this PR, because of bash-4.xisms in
build-utils.sh, for example on line 572:
```
if [[ -v _builder_params[$e] ]]; then
```
Fixes#6981.
Longpress menus were being triggered on any detected movement on keys on
Android. This would cause rapid typing to periodically fail as the user
would make a single-pixel movement while typing, which would then block
subsequent key events.
This issue was introduced in #6637, which resolved a somewhat related
problem with sticky longpress menus.
The fix is in three parts:
1. Remove the touch movement detection which caused the primary problem
2. Address some logic issues around visibility of `subkeysWindow`
3. Introduce a new 'scroll' gesture handler which detects a negative-y
movement above a 5px threshold, to open the longpress menu.
The 5px threshold is the minimum default used by Keyman Engine for Web.
However, it may not be ideal, and we should consider moving to using the
0.25 x row height value that Keyman Engine for Web uses in a future
update. However, I do not consider this to be a reason to block this
fix, as it would require significant extra engineering.
The back story:
Currently Keyman for Android reports errors sent to the console via
`console.error()` into Sentry but sentry-manager itself does not. This
means that Keyman for iPhone and iPad and other users of sentry-manager
do not report these errors. Many of these errors are important.
What's worse is that Keyman for Android's error reporting here (via the
`sendKMWError()` function in Keyman Engine for Android) does not capture
stack traces, and so many of the errors we get do not have enough
information to resolve them.
Furthermore, by having `sendKMWError()` in Keyman for Android, we
capture exceptions and other program errors twice -- once on the web
side, and once on the Java side -- this adds noise to our error
reporting. Sentry also tends to lump many unrelated `sendKMWError()`
events together, so tracking resolution to the errors is painful.
The fix:
This adds a patch to sentry-manager to capture `console.error()` and
`console.warning()` events and report them through Sentry's normal error
reporting, and disables the `sendKMWError()` report (although we leave
the breadcrumb in place for when there are later, related Java errors).
There is a Sentry integration called CaptureConsole, but it does not
support capturing stack traces until v6.14
(https://github.com/getsentry/sentry-javascript/pull/4034). Updating
Sentry to 6.14 or newer is a bigger job (due to ES6 baseline req. etc.)
Note that Keyman for iOS currently has some other stubs in place
overriding the `console.*` functions. These should be removed for
release builds, so that we can use this pattern instead. I will try and
tackle this in a follow-up PR (I will build it on my mac so I can test
it).
A sample error report captured with this mechanism (no sourcemaps here
because this is a -local build):
https://sentry.io/organizations/keyman/issues/3401287467/events/c40fd2cebb7743cc8dfe72e0dd34bf65/?project=5983524
I am proposing we back-port this to 15.0-stable as we are missing a lot
of data in many of our error reports on Android.
This fixes crash reported as #6703. This issue was first reported in
14.0.282-stable. I have done a careful review of changes in 14.0.282
(and 14.0.281) but have been unable to find any changes that could have
bearing on this.
The basic issue is that there appears to be some circumstances where
`KMManager` thinks that it has a keyboard loaded (ref
`SystemKeyboardLoaded` variable), but `KMKeyboard.currentKeyboard` is
still `null`.
The crash has been reported for only a very small set of users, 119 at
time of fix, but average reports per user is over 100. As is usual with
this type of thing, a small fraction of those users are reporting the
majority of crashes. I have not found any real commonality across the
error reports -- they are geographically dispersed, across multiple
device types and Android versions.
Note that this addresses the error at hand but as I am unable to
reproduce the issue, does not necessarily address the root problem, so
there may still be other issues reported even after this is fixed.
A longer-term refactor would eliminate `SystemKeyboardLoaded` because
from what I can tell, we should always be able to determine that from
the state of `KMKeyboard.currentKeyboard`. However, the state
entanglement is a lot deeper than just those two variables, with cross
references to keyboard indexes between `KMManager` and `KMKeyboard`
which need to be resolved (`KMKeyboard` should *never* refer to
`KMManager`).
Relates to #5816.
Moves folders under common/core/web to common/web:
* input-processor -> common/web/input-processor
* keyboard-processor -> common/web/keyboard-processor
* tools/recorder -> common/web/recorder
* tools/sentry-manager -> common/web/sentry-manager
* utils -> common/web/utils
Updates scripts and configuration to point to new folders.
