bug(ios): paragraph-initial lone diacritic deletion desynchronizes context, also deletes preceding newline
- Dominant language
- Pascal
- Stars
- 534
- Forks
- 143
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 113
Description
As discovered during user-testing of #10589, properties of the iOS `textDocumentProxy` interface, its asynchronous management of the active, jumping context window, and of Swift's handling of `String` data all come together to cause some nasty unwanted effects in certain scenarios.
While the exact cut-off point where the internal 'context window' jumps may vary from iOS device to device, the following repro should exhibit the problem pretty simply:
1. Find a keyboard that can emit exposed, free-standing diacritics or combining marks. For example, my [diacritic_rota](https://jahorton.github.io/diacritic_rota.kmp) keyboard used for testing the implementation of gestures.
2. Press ENTER, then type a diacritic.
3. (**optional**) _**Deactivate the Keyman keyboard**_ - you can do this next part with the actual iOS system keyboard!
4. Press Backspace.
One of two things will happen (assuming the context-window bit is properly set up):
1. The application and keyboard will instantly crash:
https://github.com/keymanapp/keyman/assets/25213402/1544ed57-f692-4bc9-b0fa-f984885f16b8
2. The ENTER key's newline will _also_ be deleted.
Note - this is with Keyman fully deactivated! Naturally, the same things happen when Keyman is active, likely for the same reasons.
For some other thoughts on this, https://github.com/keymanapp/keyman/pull/10589#issuecomment-1956054950
Part of me wonders if it's possible to work around by tracking the context manually on the iOS side and undoing the newline's deletion by use of our tracked data. It's only an idea, though, and it's likely too big a project to tackle during the beta cycle.
Contributor guide
Assessment
This issue has not been assessed yet.