keymanapp
fix(web): key preview stickiness ðŸª
Fixes only part of #10592.
Key previews should no longer "stick", even after rapid typing. Does not fixed stuck highlighting or cases where tapped keys appear to be ignored, however.
Note that this only fixes a small part of the overall problem; there are a lot of other aspects to the behavior reported by #10592 that will be addressed in followup PRs, hence this receiving an emoji symbol to represent the 🪠chain being started here.
As for the internal details behind what this PR fixes: there were a couple of code paths that cancelled the preview-host controller but didn't unset it... while some of the logic for showing a new preview requires that "unset". Adding such statements to the affected code paths appears to resolve the sticky key-preview behaviors.
@keymanapp-test-bot skip
As this PR seeks to address a host of related known errors but only fixes a bit of them, specifying a proper user test at this point would be quite tricky. #10843 will host the main user testing suite for this PR chain, as it exists as the final "rung" of this PR "ladder."
User Test Results
Test specification and instructions
User tests are not required
Test Artifacts
- Android
- Developer
-
iOS
- Keyman for iOS (simulator image)
- FirstVoices Keyboards for iOS (simulator image)
-
TestFlight internal PR build version -
17.0.296 (0.10778.10623)
- Keyboards
- Web
- Windows
![keymanapp-test-bot[bot] avatar](https://avatars.githubusercontent.com/in/133554?v=4 "Published by a pub.dev verified publisher"){kind=small}
Should probably refactor the paired call to ensure those are always done together; just noted that the longpress codepath also lacks a paired call. L628ish.
Oh right, I didn't actually do the merges yesterday b/c it was pretty late when everything got cleared. I should get on that.
