Prosemirror: cursor problem with emoji

Created on 17 Oct 2016  路  5Comments  路  Source: ProseMirror/prosemirror

When using the built-in emoji popup in MacOS, the inserted emoji is not at the right place. I have tested it on Mac 10.11.6 and 10.12.12

Our project is: https://bitbucket.org/atlassian/atlaskit/overview

Demo is: https://aui-cdn.atlassian.com/atlaskit/pr/stories/75b8c320d76827ac6727d0cc3e8b4e6cfe1de8d9/?selectedKind=ak-editor-bitbucket&selectedStory=Markdown%20preview&full=0&down=1&left=1&panelRight=0&downPanel=kadirahq%2Fstorybook-addon-actions%2Factions-panel

Recording: http://recordit.co/tzI1vr4ByB

I have tried your online demo: https://prosemirror.net/demo/basic.html, the cursor problem exists too. It somehow jumps to the left of the emoji after inserting it:

Alt text

  • The problem doesn't surface with the insert symbol/symbol in a window mode - it only happens when adding emojis through the hovering tooltip-like popup
  • It doesn't happen when copying and pasting emojis.
  • We can't reproduce it using OSX multibyte input methods, international keyboards - i.e. Chinese, Japanese etc.
  • The (broken) behavior is different in our editor. We believe it might be because of schema differences - here's the source code for our schema

Most helpful comment

I was able to reproduce this. The good news is that it did not happen on ProseMirror 0.12. The bad news is that it happens all the time on 0.10, and I wasn't able yet to figure out why it happens there but not on 0.12.

It appears to be an OS X bug unrelated to ProseMirror as such. When you set the selection using JavaScript and then insert an emoji using this method, whatever is driving that emoji UI will insert the emoji where the selection used to be, the last time it was set directly by the browser, and will sometimes have it replace all text between that point and the current cursor position. I've pasted an example that triggers it in a plain contenteditable element at the bottom of this comment.

So 0.12 does _something_ different, which somehow suppresses this bug. I spent a while trying to figure out what, but was unsuccessful. Is upgrading to 0.12 on the short term an option for you? If so, could you see if the problem is also gone for you on 0.12 (for example on the demos on the website)?

<!doctype html>
<meta charset=utf8>

<div contenteditable=true style="border: 1px solid red">
  <p>foo</p>
  <p>bar</p>
</div>

<p>Click the top paragraph to focus the editable element. The script
will move the selection to the bottom paragraph. If you insert an
emoji using OS X's ctrl-cmd-space menu, it will appear where you
originally clicked, not at the selection.</p>

<script>
let div = document.querySelector("div")
div.addEventListener("focus", function() {
  setTimeout(() => {
    let sel = document.getSelection(), range = document.createRange()
    range.setEnd(div.lastElementChild, 1)
    range.collapse(false)
    sel.removeAllRanges()
    sel.addRange(range)
  }, 100)
})
</script>

All 5 comments

So the problem is that the next inserted character ends up in front of the inserted emoji? I don't have a working mac at the moment, so it might be a while before I can debug this.

@marijnh we actually have some more interesting behavior that you can watch here: http://recordit.co/tzI1vr4ByB

With our schema it seems to be removing parts of the text after inserting emoji - almost like it was undoing back ...

I was able to reproduce this. The good news is that it did not happen on ProseMirror 0.12. The bad news is that it happens all the time on 0.10, and I wasn't able yet to figure out why it happens there but not on 0.12.

It appears to be an OS X bug unrelated to ProseMirror as such. When you set the selection using JavaScript and then insert an emoji using this method, whatever is driving that emoji UI will insert the emoji where the selection used to be, the last time it was set directly by the browser, and will sometimes have it replace all text between that point and the current cursor position. I've pasted an example that triggers it in a plain contenteditable element at the bottom of this comment.

So 0.12 does _something_ different, which somehow suppresses this bug. I spent a while trying to figure out what, but was unsuccessful. Is upgrading to 0.12 on the short term an option for you? If so, could you see if the problem is also gone for you on 0.12 (for example on the demos on the website)?

<!doctype html>
<meta charset=utf8>

<div contenteditable=true style="border: 1px solid red">
  <p>foo</p>
  <p>bar</p>
</div>

<p>Click the top paragraph to focus the editable element. The script
will move the selection to the bottom paragraph. If you insert an
emoji using OS X's ctrl-cmd-space menu, it will appear where you
originally clicked, not at the selection.</p>

<script>
let div = document.querySelector("div")
div.addEventListener("focus", function() {
  setTimeout(() => {
    let sel = document.getSelection(), range = document.createRange()
    range.setEnd(div.lastElementChild, 1)
    range.collapse(false)
    sel.removeAllRanges()
    sel.addRange(range)
  }, 100)
})
</script>

Hi @marijnh, that's great news. We would like to upgrade to the newer version, but considering the time frame, we might not have enough time to upgrade it in our MVP. Thanks for looking into it. 馃憤 We would like an upgrade when we are ready. :)

I can confirm it's gone on 0.12. The cursor "jerks" a little bit sometimes, shifting by one position, but the symbol is inserted at the expected offset. Thanks @marijnh

Was this page helpful?
0 / 5 - 0 ratings