prosemirror: Backspacing out inline nodes on mobile sometimes breaks

From this comment in #543 via @fredguile:

@marijnh I’m also testing the composition branch and something noticeable happens with inline nodes:

As you can see the first time I hit backspace it works, second time actually most of the time it behaves like this) it doesn’t delete the node and actually duplicates text after it.

That’s easily reproduceable, you can take my demo example from here and link it against prosemirror-view composition branch.

Is there anything wrong in my code or could this come from the composition fix?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 20 (12 by maintainers)

Most upvoted comments

Hi @marijnh, at last, I may have good news regarding inline nodes on Android. I’ve found a way to handle them based on all your aforementioned inputs (thanks for that!), plus working with our seasoned Android developers that found a way to forcefully send the missing keyup/keydown events.

I’ve made a video that is worth watching instead of a long explanation: https://www.dropbox.com/s/y4xy3oqayqfa453/about inline nodes.webm?dl=0

As you can see it’s combining several of our aforementioned tricks:

  • using inline divs for representing inline nodes,
  • I also found that we would then have to render paragraph using DIVs (instead of Ps),
  • and this works of course if we override the Android’s InputConnection to forcefully send the missing key events. Without this, we’d end up with the previous symptom where BACKSPACE doesn’t delete the inline node.

I’m discussing with the team if we could afford rendering our paragraphs using DIVs (I don’t think that’s a huge change, might actually be doable).

The good thing is that this solution doesn’t depend on prosemirror-view composition branch, so we could rollout a fix using the current prosemirror-view version. Asides, I think the composition branch is still be beneficial to us for solving different problems, mostly IME related. But now we can tackle these problems separately (and in another issue).

What are you thoughts about this solution?

(as usual I’ve made the code used in the video available here)

Thanks for the info! This would have been a rough one to figure out without your help. I thought I’d share this gist showing how we overrode the Android InputConnection on react-native in case anyone else runs into this issue trying to support RN. https://gist.github.com/dakhipp/72377353da53d9b106d705a0e8c64c81

I’m discussing with the team if we could afford rendering our paragraphs using DIVs (I don’t think that’s a huge change, might actually be doable).

Do you really need to do that? Doesn’t an inline node (say a <span>) styled with display: block have the same effect? The problem, as I suppose you’re aware, is that the HTML parser will close a <p> when it sees <div>. It would be nice if you can avoid using nonsemantic markup for your paragraphs.

The video had no sound for me—was the text in the editor its intended content? If so, I’d really prefer just getting the text, next time, without video!

Hi @marijnh, at last, I may have good news regarding inline nodes on Android. I’ve found a way to handle them based on all your aforementioned inputs (thanks for that!), plus working with our seasoned Android developers that found a way to forcefully send the missing keyup/keydown events.

I’ve made a video that is worth watching instead of a long explanation: https://www.dropbox.com/s/y4xy3oqayqfa453/about inline nodes.webm?dl=0

As you can see it’s combining several of our aforementioned tricks:

  • using inline divs for representing inline nodes,
  • I also found that we would then have to render paragraph using DIVs (instead of Ps),
  • and this works of course if we override the Android’s InputConnection to forcefully send the missing key events. Without this, we’d end up with the previous symptom where BACKSPACE doesn’t delete the inline node.

I’m discussing with the team if we could afford rendering our paragraphs using DIVs (I don’t think that’s a huge change, might actually be doable).

The good thing is that this solution doesn’t depend on prosemirror-view composition branch, so we could rollout a fix using the current prosemirror-view version. Asides, I think the composition branch is still be beneficial to us for solving different problems, mostly IME related. But now we can tackle these problems separately (and in another issue).

What are you thoughts about this solution?

(as usual I’ve made the code used in the video available here)

Ah, okay, yes, that’s another bug. But again a difficult one—as you probably know, Chrome Android doesn’t fire useful key events for keys pressed on the virtual keyboard. Thus, we can’t apply our own, reasonable backspace logic, but have to let the default behavior go through and then check whether it looks like the result of backspace. If a backspace press does nothing, ProseMirror has nothing go to on.

And indeed, it seems like backspacing out an uneditable block doesn’t work on mobile. Have you opened an issue on the Chrome tracker yet?