keyman
keyman copied to clipboard
keymanapp
bug(web): internal null error occurred during caps multitap
Describe the bug
While trying to identify an older test page useful for testing a currently-active PR, I happened upon this error when using web/testing/caps-lock-layer-3620/:
Note the floating undefined in the source area - ruleBehavior itself is undefined, but we're only null-guarding its transcription property here.
The KeyEvent that produced this: I quickly double-tapped the 'shift' key while using a tablet form-factor - either from the default layer or the shift layer.
To Reproduce
- Go to the Web testing page
web/testing/caps-lock-layer-3620/. ("Test Caps Lock Layer (3620)") - Click on the text area to summon the OSK.
- Quickly double-tap the shift key to access the CAPS layer.
- Check the JS console
- Alternatively, if you're doing this in Chrome with its mobile-device emulation mode, Chrome may auto-break when the error occurs! How helpful!
Note that the caps-lock layer still appears... but the first key following the error appears to get "swallowed".
Expected behavior There should be no JS error, nor should the following keystroke be swallowed. I imagine the former causes the latter, but we can't be sure without further investigation.
KeymanWeb:
- KeymanWeb Version: 15.0.260
Other notes: I seem to recall seeing Sentry errors with a similar error and call-stack. I'll try to find 'em and link them to this issue. Of course, the question there is whether or not this only happens from multitap cases.
I believe this was fixed in #6789 (15.0.261)
For some definitions of "fixed"... but it feels like possibly-bad design for us to intentionally be producing null RuleBehaviors from multitaps. I want to make sure this scenario is actually reasonable.
In other words, does that fix affect the cause, or just an effect of the actual cause?
The null guard is absolutely 100% necessary because a null RuleBehavior is possible for layer switch keys. The very next line of code in #6789 tests for a null RuleBehavior!
So it does fix the cause. We can argue about whether it's a bad design, but it's your design I think? In any case, any redesign for multitap is part of the gesture work and probably does not need to be tracked as a separate issue.