DOM changes are diffed against the old text and then interpreted as their minimal patch. IME will often do a lot of deletion and reinsertion of text for things that boil down to simply inserting a character, so in many cases this aligns with what you’d expect. I guess in this case it’s a little odd, but it still seems like an accurate description of the change that was made.
I don’t have access to a computer right now, but if I’m not mistaken, I’m pretty sure the beforeinput fires with the actual inserted word (relevant) as a insertText. Despite this, ProseMirror only shows a in handleTextInput.
I’m not sure how that works under the hood, but given that the beforeinput fires as expected, it does seem addressable to me if you believe that it’s within the scope of ProseMirror’s mission.
I can also imagine a scenario where a different misspelling leads to non-consecutive characters needing to be replaced. I’m not sure how handleTextInput would be expected to behave in that case.
Doing the replacement via the suggestion bar does not result in the same problem, which further makes me think this might just be a small oversight in handling rather than a fundamental limitation.
As far as why this is problematic for us, we patched handleTextInput to output the received text after doing a little pre-processing, but without receiving the proper text users will see the word replaced with a single letter.
Thank you again for your reply and for your amazing project. It’s really a marvel to me that one person could be responsible for ProseMirror.
So what you’re seeing is that the from/to passed to handleTextInput cover the entire word, but the text string is only one letter of the replacement text? I don’t have an iOS device I can test on right now, but if that’s the case, that would definitely be considered a bug.
Yes that’s correct. I was able to produce this on iOS simulator, but I understand all Apple hardware is not easy to come by.
I’m not very experienced with iOS myself but I can try to get a recording of what happens or otherwise detail this better so that you can have a more complete picture of the issue. Most important, I assume, would be capturing the beforeinput event details for you. Does that seem like a reasonable supposition?
When I try this, the from/to positions passed to handleTextInput point precisely around the actual (minimal) range replaced, and thus accurately describe the document update.