While analyzing some odd behaviors I ran into while locally testing out #16223, I found errors like the following occurring when swapping back and forth among keyboards, often to gff_amharic:
[Error] Could not find and prioritize output key in its fat-finger distribution
(anonymous function) (keyman-sentry.js:4295)
raiseKeyEvent (keymanweb-webview.js:17643)
(anonymous function) (keymanweb-webview.js:16959)
emit (keymanweb-webview.js:160)
(anonymous function) (keymanweb-webview.js:11999)
(anonymous function) (keymanweb-webview.js:78)
Promise
__async (keymanweb-webview.js:62)
This corresponds to the following block of code:
|
console.error("Could not find and prioritize output key in its fat-finger distribution"); |
This line does not appear in 18.0 releases - it was added during 19.0 development in #14670. That said, there are a couple of mysterious Sentry errors we've seen that have similar properties. (I'll tag them separately later.)
While I have, as of yet, been unable to find the true root cause, I have learned a great deal about the error state.
- A deep-copy version of the instance is nearly always available - but as the instances don't match, the lookup fails.
- To be clear, there should not be clones or deep-copied instances. Yet, they are present, plain as day, when debugging.
- Nearly all values of the instance do match.
- The one point of difference I've discovered thus far is that sometimes, the
.hintSrc instance will be different (though its contained values still match). Other array-valued fields hold the same instances.
- Somehow, the
ActiveKey key-spec values being returned from the gesture-processing subengine fail to match those from the actual keyboard, keyboard layout, and OSK.
When typing into the developer console, the following expression always returns true, whether or not an error arises:
keyman.osk.vkbd.layerGroup.layers.default.rows[0].keys[0].spec == keyman.osk.vkbd.layoutKeyboard.layout('phone').layer[0].row[0].key[0]
That is, the key-spec held by the OSK matches that of the raw specifications returned from the main keyboard object. (These will also match those in fat-finger distributions.)
Meanwhile, the following expression changes when in a state where the error occurs:
keyman.osk.vkbd.layerGroup.layers.default.rows[0].keys[0].spec == keyman.osk.vkbd.gestureEngine.config.targetRoot.childNodes[0].childNodes[0].childNodes[0].childNodes[0].childNodes[0].key.spec
Before the error state is primed, the above expression returns true. The same key elements are being referenced, so the same key-spec instances are also referenced.
When the error state is primed, somehow the expression returns false - the gesture engine has had some portion of the referenced element hierarchy replaced in some manner, despite my inability to find any such mechanism in the actual code base. This appears correlated to an keyman.osk.refreshLayout() call (which is triggered by either version of "step 3" in the repro below), as the only ways I know to prime the error state require that it be called.
I was able to identify a fairly consistent reproduction for this, at least using the latest epic/autocorrect builds (19.0.254-alpha, with the branch merged in).
- Using Keyman for iPhone and iPad, install the
gff_amharic keyboard package.
- Type a few characters with the keyboard. (The error will rarely, if ever, occur in this step.)
- Do eIther one of the following.
- Rotate the device once.
- Activate the top-right triple-dot dropdown menu, then back out of it.
- Type one or two characters with
gff_amharic (still active). The error will usually occur by this point.
In this state, we can revert back to the state of steps 1 and 2! To do so, simply swap keyboards and then reactivate gff_amharic.
While analyzing some odd behaviors I ran into while locally testing out #16223, I found errors like the following occurring when swapping back and forth among keyboards, often to
gff_amharic:This corresponds to the following block of code:
keyman/web/src/engine/src/osk/visualKeyboard.ts
Line 1652 in e1d01a2
This line does not appear in 18.0 releases - it was added during 19.0 development in #14670. That said, there are a couple of mysterious Sentry errors we've seen that have similar properties. (I'll tag them separately later.)
While I have, as of yet, been unable to find the true root cause, I have learned a great deal about the error state.
.hintSrcinstance will be different (though its contained values still match). Other array-valued fields hold the same instances.ActiveKeykey-spec values being returned from the gesture-processing subengine fail to match those from the actual keyboard, keyboard layout, and OSK.When typing into the developer console, the following expression always returns
true, whether or not an error arises:That is, the key-spec held by the OSK matches that of the raw specifications returned from the main keyboard object. (These will also match those in fat-finger distributions.)
Meanwhile, the following expression changes when in a state where the error occurs:
Before the error state is primed, the above expression returns
true. The same key elements are being referenced, so the same key-spec instances are also referenced.When the error state is primed, somehow the expression returns
false- the gesture engine has had some portion of the referenced element hierarchy replaced in some manner, despite my inability to find any such mechanism in the actual code base. This appears correlated to ankeyman.osk.refreshLayout()call (which is triggered by either version of "step 3" in the repro below), as the only ways I know to prime the error state require that it be called.I was able to identify a fairly consistent reproduction for this, at least using the latest epic/autocorrect builds (19.0.254-alpha, with the branch merged in).
gff_amharickeyboard package.gff_amharic(still active). The error will usually occur by this point.In this state, we can revert back to the state of steps 1 and 2! To do so, simply swap keyboards and then reactivate
gff_amharic.