I’m seeing some issues with composition in Firefox on Mac while using composition near a widget. The browser seems to get confused when moving the cursor, inserting extra characters and other odd behaviour. I am not a regular IME user, but I’m fairly certain this behaviour is incorrect, and is not the same when doing the same thing on a line with no widget.
Using this example, and using Japanese - Romaji input source with a virtual keyboard to make it easier to follow (the behaviour is the same with a physical keyboard), I recorded the following:
For comparison, here is the same on a line without a widget:
Thanks for fixing that. Unfortunately, trying the same example again (it appears as though Try CodeMirror has view 6.9.3), I’m afraid it now seems differently broken on Mac. When entering a second composition, the down arrow key gets stuck when trying to move down to an emoji in the menu, and pressing the left arrow key then causes characters to appear and other oddness.
Indeed. I was testing with special character widgets, which, because they aren’t zero-length, didn’t show this issue. Attached patch seems to help with zero-length widgets.
I’ve checked again, and checked in the Network tab in the Firefox dev tools and confirmed that the patch is present in the code running in the browser, and the issue is still there. Note that the use of Romaji is sigificant; the issue I’m seeing is specifically when using the up or down arrow keys to reach an emoji in Japanese. I don’t see the same with, for example, an emoji in Pinyin.
Trying to piece together what you’re doing from a screencast is very difficult for me. Please provide the steps to reproduce this in written form (along with a clear enough description of the observed and expected behavior for someone who knows zero Japanese to understand what’s going on).
Fair enough. It’s quite difficult to make an animated GIF that both shows the problem clearly and is under the 4MB limit.
On a Mac, enable the “Japanese - Romaji” input source. In the settings for it, ensure the “Live Conversion” check box is checked. Make sure the Japanese input source is active.
Press the down arrow key repeatedly until you come to what looks like the axe emoji ()
The down arrow at this point has no effect and things get into a weird state. Pressing the left arrow key now starts inserting stuff into the editor. The desired behaviour is that the emoji is selected in the menu and appears in the editor, and that pressing the left arrow key doesn’t insert anything before the text you’re currently composing.
Actually, even more simply, I’ve just spotted that the left arrow key always does weird stuff while composing in Japanese immediately after a widget containing text:
In the example, type “o” to start composing
Press the left arrow key a few times. It looks as though it’s trying and failing to edit the read-only text in the widget.
I’ve seen similar but not identical issues with Romaji and emoji in Chrome too, but less pronounced. I can try to isolate one if you need.
I was able to reproduce something like this, though somehow the options I get are not exactly the way you described them, and in fact often differ between attempts to reproduce locally that have me performing the exact same actions.
I don’t believe I have entirely solved all issues in this class. The root of the problem is definitely a bug in Firefox or the IME system, which stops working (or even goes completely corrupt, showing empty drop-downs of options or duplicating text) as soon as you look at it sideways. But attached patches try to reduce the amount of sideways-looking the editor does, avoiding some cases where nodes next to the composition where removed during composition, and fixing a bug where the editor incorrectly moved the selection.
@aetonplease start a new thread or issue when reporting something different. Keeping track of this mess is bad enough already, I don’t need multi-bug-threads in my inbox to make it even more confusing.
@marijn Sorry about that - I noticed the other issues while investigating this issue, and thought it worth pointing them out in case they were different facets of the same problem (which would also imply that it affected other browsers, not just Firefox). I’ll delete the comments above and open new issues for anything that still exists after the latest release of @codemirror/view .
)