isComposing gets out of sync on iOS?

I could be mistaken but it seems like the isComposing of the view can get out of sync (at least in iOS) when IME is involved. I’m on iOS 14.8 using the prosemirror.net editor along with the japanese (kana) keyboard (perhaps happens with other that use IME?). The steps appear to be:

Clear the contents of the editor.

Switch to the japanse keyboard and type a few characters (e.g. the key in the lower right of this image) image.

Then tap B to toggle/enable the bold mark. At this point internally in prosemirror i believe the setMark ultimately calls clearComposition which sets the isComposing flag back to false.

Now press another key - e.g. the one immediately to the right of the one pressed above. The result is that no text is displayed in the editor. It seems that it is actually updating the content (or so it seemed while debugging it) but then that is getting stepped on. Ultimately I think the issue is that the isComposing flag remains false but the editor is still within a composition. Perhaps the isComposing state should be reinitialized from the isComposing of any key event (assuming that is present/supported by the browser)?

I guess I’ll just log what I find here in case it helps someone. Originally I noticed issues with changes made to formatting (e.g. toggling bold mark) during an IME composition not taking effect in Android. From recollection it wasn’t any different than a vanilla contentEditable so I didn’t mention anything here. I was planning on working around that by trying to commit/close the current composition. The only way I had found to do that was to call blur on the editor’s dom. The blur would synchronously cause the compositionend so the fact that the prosemirror cleared its composing worked because both were in sync. Interestingly, I noticed that codemirror actually seems to call blur/focus when it goes to clear/end its internal composition state so I do wonder why prosemirror does not. Not that that helps me here because when I found this issue in ios I found that that does not result in a compositionend nor do other things I had tried (like manipulating the dom selection or explicitly focusing another element). I haven’t delved into what prosemirror is doing to the dom that puts it in a bad state yet and not sure i have the time so I may just disable formatting changes when composing is true so one has to commit the current composition before changing the formatting.

Oh and i had tried to just trigger/raise a compositionstart on the next keydown tunnel (since it was still in a composition but the editors composing was false) and while composing of the editor went to true it still wouldnt show subsequent keys. So presumably whatever the ime was doing to show the state of the composition was broken by some dom change made by the formatting change handling. When i get time ill try to see what was changed if possible.