Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Duplicated characters in Safari with IME - unreliable cause and solution #944
There is a problem that editor duplicates text characters in Safari, when marks are applied and IME input is active.
The root cause is not 100% clear to me because I could not reliably reproduce it but I suspect it has something to do with native selection. Please bear with me, this description is a bit longer.
I have two simple test cases:
These two actions are identical, while the second one is causing troubles. I swizzled few methods to find out how stack traces differ under the hood:
In Safari, once a selection is re-selected right after
I pin pointed the issue in
There is a blocking part which should prevent re-selection from happening:
I logged the state after the if-clause from the link above (it can be done through a breakpoint):
This is the output:
The interesting part is, that an element with the cursor (
How to fix this?
I changed it to following as you can't really do too many things or even select text with an active IME input:
@marijnh, does the change make sense and could be used as a fix? I can create a PR if you are not against it.
I'm trying to type twice 你好, once normal and once in bold. I can't get bold active in
Please check the recordings here (I could not paste the image here as it's somehow not playing the full length):
I see that someone also stumbled on this IME + mark issue:
I tested it on a "basic example" with 1.9.14-prerelease2 as my repo has other problems in my code.
It's "almost" there. When you type "normal bold " and then disable bold and try to type another piece of text, the mark is re-enabled in case of a space in the composition (not sure about the terminology here). I need to disable bold beforehand and start the composition without undesired mark, then it works as expected.
Thanks a lot for fixing the original issue. I will close this as the original problem has been resolved. I'm happy to do further testing/debugging if you have other changes for the mark issue.
Thanks for the feedback. Do I understand correctly that the problem occurs when you try to enable/disable marks during a composition? If so yes, that isn't handled yet—and can't be handled without interrupting the composition, since the editor can't touch the DOM that's being composed without interrupting. But maybe interrupting is the right thing to do there. What would be the expected behavior for you?
Thanks. I can reproduce the issue with that IME. It seems it does something odd on 'word' boundaries that causes the whole composition to revert to the style of its context. I can reproduce the same behavior in a non-ProseMirror contenteditable element, and I'm not sure how to work around it. Filing an issue with Safari might eventually help, if you're lucky (just going through the thing you showed in an editable element that has some key combo wired up to