[prosemirror-view] Rogue br tag when deleting through widget

[RichieAHB]

Issue details

Backspacing through absolutely positioned widget decorations introduces a rogue br tag

Steps to reproduce

Open this doc, select at the end, backspace through the doc

https://glitch.com/edit/#!/join/b5a9d33d-c933-4594-995c-6b756d47e977

ProseMirror version

Affected platforms

• Chrome
• Firefox (untested)
• Internet Explorer (untested)
• Other

Screenshots / Screencast (Optional)

http://recordit.co/wWtSoyWxQ7

[marijnh]

Did you test with prosemirror-view 1.4.1 (or 1.4.2)? This sounds a lot like #799

[RichieAHB]

It's tested with 1.4.2 unfortunately - interestingly, it doesn't seems to be a problem when the widget isn't absolutely positioned.

[RichieAHB]

Given it does sound like #799 I tested it in FF and it works so I think it's probably a very similar issue.

[RichieAHB]

Looking at your patch for #799 it seems the problem here (aside from Chrome blithely throwing in a br) is that, in the above example, parent.childNodes[toOffset - 1] is actually the widget decoration and not the br tag, which is actually the node prior to the widget decoration. Essentially the decoration gets in the way of this check, which seems to mean that just using toOffset-- a couple more times isn't really feasible as it would remove the decoration too.

[marijnh]

Does this patch solve your issue?

diff --git a/src/domchange.js b/src/domchange.js
index b58ff4a..c258d1e 100644
--- a/src/domchange.js
+++ b/src/domchange.js
@@ -118,9 +118,15 @@ function parseBetween(view, oldState, range) {
     if (!selectionCollapsed(domSel))
       find.push({node: domSel.focusNode, offset: domSel.focusOffset})
   }
-  // Work around issue in Chrome where backspacing sometimes replaces the deleted content with a random BR node
-  if (browser.chrome && view.lastKeyCode === 8 && toOffset > fromOffset &&
-      parent.childNodes[toOffset - 1].nodeType == "BR" && !parent.childNodes[toOffset - 1].pmViewDesc) toOffset--
+  // Work around issue in Chrome where backspacing sometimes replaces
+  // the deleted content with a random BR node (issues #799, #831)
+  if (browser.chrome && view.lastKeyCode === 8) {
+    for (let off = toOffset; off > fromOffset; off--) {
+      let node = parent.childNodes[off - 1], desc = node.pmViewDesc
+      if (node.nodeName == "BR" && !desc) { toOffset = off; break }
+      if (!desc || desc.size) break
+    }
+  }
   let startDoc = oldState.doc
   let parser = view.someProp("domParser") || DOMParser.fromSchema(view.state.schema)
   let $from = startDoc.resolve(from)

[RichieAHB]

I actually already tried that and it removes the decoration that was skipped over, I considered mutating the NodeList but that might be heresy?! Also there are maybe a few issues in that patch if you were still looking at it:

• I think it should be toOffset = off - 1 (I'm assuming toOffset is exclusive)
• node.tagName === "BR" [thought you'd written nodeType again but saw your other comment]
• result.chrome.

[RichieAHB]

Actually - I think I had nodeType in my code too ... this may work now work for the backspace case, will double check. Although, unlike #799, it does have a delete case too ...

Edit this does work on backspace but delete is harder to fix as, in the example, Chrome puts the br after the space character at the cursor 🙄

To repro just place the cursor behind the first t in the example and press the delete key.

[RichieAHB]

FYI - for now I can sort of fix this for my use case using elements that are not absolutely positioned.

[ahallora]

I stumbled upon this issue today with an inline node that contains an absolute positioned element.

<span>
    <span class="input"></span>
</span>

When I delete the text before the inline node (using backspace/delete) Chrome inserts an empty <br> as the first element in the paragraph resulting in an undesired line-break. It works as expected in Firefox.

In this demo you can see, the only difference between the two inline nodes is the 2nd span.input have a different background color and a different position not being absolute, resulting in the correct behaviour, while the blue node, containing an absolutely positioned inner element, gets a <br> injected before it.

How to stop chrome from inserting the <br> ?

[marijnh]

This appears to be a Chrome bug (it reproduces even in a plain contenteditable element). I don't see much of a way ProseMirror can fix that, except adding some dodgy code to try and detect and undo it. But since that kind of code often ends up producing problems, and this is a very specific and hopefully rare scenario, that doesn't seem like a good approach.

I'd recommend just finding a DOM structure/styling that avoids the Chrome issue.