This error has been logged for every start of Keyman Engine for Web in
embedded contexts, but nothing bad ever happens. It does not really seem
to be anything we need to worry about. (It may be that the
`setDefaultKeyboard()` call will never return true, but it is still
harmless in any case.)
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.
Updated various places in Keyman for Windows to show the full
VersionWithTag rather than the short version number we had been
previously showing:
- Support tab
- System Information, About dialog
Updated various places in Keyman Developer to show the full
VersionWithTag rather than the short version number we had been
previously showing:
- About dialog
- Welcome screen
- Installer
- kmcomp help
- kmconvert help
- kmanalyze help
- kmdecomp help
This should help when testing to verify that we are testing the right
version.
Also fixed the keymansentry path when running command line C++ programs
from source repo.
Fixes#6799.
Caps Lock state management for touch layouts was not quite right -- it
touched the base Caps state variables rather than just the event Lstates
property. This meant that it was impossible to track the physical Caps
Lock key separately to the touch layout layer, and that the two states
would interfere with each other.
Fixes#6799.
For KeymanWeb compiled keyboards, readonly groups should never emit any
output. Rules in these groups permitted only to:
* `use` other readonly groups
* `call` external functions (which MUST NOT emit output)
* `set`, `reset` or `save` store values
The base kmx compiler does emit output for rules in readonly groups.
Thus, the KeymanWeb compiler, when it transpiles from the generated
.kmx, needs to omit output for any readonly group, while avoiding any
other potential change in behaviour.
Fixes#6799.
For KeymanWeb compiled keyboards, readonly groups should never emit any
output. Rules in these groups permitted only to:
* `use` other readonly groups
* `call` external functions (which MUST NOT emit output)
* `set`, `reset` or `save` store values
The base kmx compiler does emit output for rules in readonly groups.
Thus, the KeymanWeb compiler, when it transpiles from the generated
.kmx, needs to omit output for any readonly group, while avoiding any
other potential change in behaviour.
