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.
