Empty paragraphs are pasted in with an extra <br> when copied from Google Docs

[ChiriVulpes]

I don't actually know if this is Google Docs's copy format in specific or if this would always occur for empty paragraphs like this.

To reproduce:

1. Open this document https://docs.google.com/document/d/1eALoiE4ufLdYqKaGYfHrT3cnVHpYW-o1rUzHs2Q1yFY/edit
2. Ctrl + A, Ctrl + C
3. Paste into the example editor https://prosemirror.net/
4. The resulting text is paragraph 1, followed by a paragraph of two blank lines, followed by paragraph 2

[marijnh]

The HTML we get in this case looks, if I remove the attributes, like this:

<p><span>Paragraph 1</span></p><br><p><span>Paragraph 2</span></p>

ProseMirror assumes the stray <br> actually stands for a break element, so it parses it to a hard_break node. That node must occur in an inline context, so it gets a parent paragraph. There is a hack in ProseMirror's parser that will drop <br> nodes at the end of their parent block, since those are typically used as placeholders in empty textblocks. But the way it completely replaces the entire paragraph with a loose break node in this situation isn't a common style, and is hard to distinguish from situations where the break node is intended to be part of the document.

[ChiriVulpes]

Hmm. Google at it again... This is going to come up a lot for the community using my application, lots of authors copy paste from GDocs. But maybe if that's not common usage for Prosemirror overall it should be fixed on my end? That would be transformPastedHTML, correct?

Edit: I went ahead and just fixed it on my end. Feel free to do what you like with this issue.

[marijnh]

I'm going to leave this open and see if more people are running into it. It's quite possible that this is a recent change in Google Docs—I'm pretty sure that last time I looked, empty paragraphs had a <p> tag around the <br> in their clipboard format.

[bZichett]

I don't think it is recent but I am not positive. Would appreciate a special case here as I sporadically paste a lot from Google docs.

[moetelo]

Right now, we're using a somewhat messy transformPastedHTML in production to handle pasting from Google Docs, MS Word and OpenOffice. However, it doesn't feel reliable enough as users report issues every few months. Plus, I'm not sure if such logic should be the responsibility of an application using ProseMirror.

It would be great if ProseMirror natively preserved the formatting of content pasted from Google Docs and other Word-like editors.

[marijnh]

It would be great if ProseMirror natively preserved the formatting of content pasted from Google Docs and other Word-like editors.

I'm not sure how you expect that to work. Firstly, ProseMirror is schema-agnostic, so it doesn't magically know how the nodes you define would map to whatever equivalent constructs exist in the various word processing systems. Secondly, as you found, these spit out all kinds of completely ludicrous HTML, and in some situations it's not even clear how to extract the semantic meaning from that.

[zunsthy]

What a hell!

<br> outside of paragraph miss info. If I set line-height, margin-top, margin-bottom for an empty paragraph, the pasted html will disappear all of them. GoogleDocs save paragraph info to first paragraph id attribute. It seems to prevent getting the same content from html in other editors.

[ChiriVulpes]

Google seems to always use just a <br> in place of <p><br></p>, I don't actually know how to fix this consistently because it's not just between paragraphs. If I put a heading, then an empty line, then a paragraph, for example, when copy-pasting into ProseMirror that single <br> between the heading and the paragraph becomes <p><br><br></p>. I don't think I can reliably use transformPastedHTML to fix this and I'm not sure what other workarounds I could even employ. Any ideas?

[dominikklein]

When I have for example the following clipboard content:

<p>test</p>
<p><br></p>
<p>test 3</p>

And paste this inside the editor, this leads to multiple line breaks instead of one:

<p>test</p>
<p><br><br class="ProseMirror-trailingBreak"></p>
<p>test 3</p>

Is this expected?

(It also happens when the initial Content has such markup.)

[marijnh]

Is this expected?

Yes. The first <br> was found in the clipboard content, so the editor assumes it refers to an actual hard break that should be part of the content. The second is just there to prevent the browser from collapsing the first one, and is not part of the actual document content.

[dominikklein]

Thanks for the explanation.

I can not completely follow, but maybe it's because of some lack of understanding.

Why should the browser prevent something, at least in our case, we have two "visible" line breaks because of that (we are using TipTap).

[marijnh]

In an editing context, you want the line after a trailing <br> to be visible, so that the user can put the cursor after the break. A <p><br></p> would just display a single line (before the break), so ProseMirror adds a dummy break at the end to make the second line show up, similar to how it adds a dummy to entirely empty textblocks to make them show up at all.

[dominikklein]

So in the end, every paragraph without real text is getting this <br class="ProseMirror-trailingBreak"> part? For the situation when only a <br> exists, it's really strange, because this leads to two visible new lines, and when you look in the source, it's only one. For sure, later in the document content, but this is not what the user is seeing at this moment.

[ChiriVulpes]

Shouldn't the assumption be that places we copy out of are using <br>'s in exactly the way that you're using them? To make empty blocks actually show?

[marijnh]

Shouldn't the assumption be that places we copy out of are using <br>'s in exactly the way that you're using them?

That's only appropriate if the content is copied from a (poorly implemented) web editor. If it's regular HTML, or an editor like ProseMirror which is considerate enough to strip off such internal details when you copy, the assumption that such <br> nodes should be dropped doesn't hold.