Japanese IME input issue with stored marks in ProseMirror editor

[r1cep]

Bug Description

When using IME to input Japanese characters with the ProseMirror editor's marks stored, the cursor is positioned to the left of the input character.

Steps to Reproduce.

1. open https://prosemirror.net/ in Chrome
2. Press the bold or emphasis button.
3. Type Japanese characters in the IME.

2024-11-07.14.49.03.mov

Browser Used

Chrome

Expected Behavior

The cursor is positioned to the right of the character you type.

Additional Context (Optional)

• Firefox and Safari do not reproduce this behavior.
• The cursor is positioned on the right side of the second and subsequent characters

I've print debugged the issue at hand, and it seems that the result of the relevant Document.getSelection method is different between Chrome and Firefox.

https://github.com/ProseMirror/prosemirror-view/blob/5c33b883d39d7d40097e1fcdf17f543d18ad502a/src/index.ts#L498-L501

Table of results of executing the relevant Document.getSelection including bold in storedMarks

browser	anchorNode.parentElement	anchorOffset
Chrome	p	0
Firefox	b	1
Safari	b	1

https://github.com/ProseMirror/prosemirror-view/blob/5c33b883d39d7d40097e1fcdf17f543d18ad502a/src/domchange.ts#L15-L25

Modifying the above parseBetween function as follows will solve this issue, but I am not sure if this is the right way to do it.

  function parseBetween(view: EditorView, from_: number, to_: number) {
    let {node: parent, fromOffset, toOffset, from, to} = view.docView.parseRange(from_, to_)

    let domSel = view.domSelectionRange()
    let find: {node: DOMNode, offset: number, pos?: number}[] | undefined
    let anchor = domSel.anchorNode
    if (anchor && view.dom.contains(anchor.nodeType == 1 ? anchor : anchor.parentNode)) {
-     find = [{node: anchor, offset: domSel.anchorOffset}]
+     find = [{ node: anchor, offset: browser.chrome && anchor.nodeType !== 3 ? domSel.anchorOffset + 1 : domSel.anchorOffset }]
      if (!selectionCollapsed(domSel))
        find.push({node: domSel.focusNode!, offset: domSel.focusOffset})
    }

[marijnh]

It appears Chrome is reporting a different selection (via getSelection) than it is actually displaying. We've had some issues like that before (see also #41467501, which still hasn't really gotten taken seriously on the Chrome side). What I am seeing is that the cursor is moved to the proper place after you confirm the composition with Enter. As such, does this impact actual editing, or is it just producing a visual discrepancy with the cursor being drawn in the wrong spot?

[r1cep]

As such, does this impact actual editing, or is it just producing a visual discrepancy with the cursor being drawn in the wrong spot?

Yes, there are cases that affect the actual editing.

2024-11-07.23.17.01.mov

The video above is an example.

[marijnh]

I think I found a workaround for this—the kludge that already existed for an issue like this on Chrome Android also applies to desktop Chrome. Attached patch enables it there.

[r1cep]

Sorry for the late response.

I confirmed that it is fixed in the PATCH version.

Thank you for the great work you've done.