Heading unexpectedly loses formatting when copy and pasting

[danielbachhuber]

Description

When I copy and paste a heading, the heading loses its formatting:

CleanShot.2023-02-13.at.09.29.20.mp4

Step-by-step reproduction instructions

1. Create a new post.
2. Add a heading.
3. Copy the heading.
4. Paste the heading.
5. Observe that your pasted heading doesn't contain the expected format.

Screenshots, screen recording, code snippet

No response

Environment info

• Reproduces in both Firefox 109.0.1 and Chrome 110.0.5481.77 on Mac
• Gutenberg 15.1.0

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[richtabor]

Came here to report this as well.

[ellatrix]

With formatting, you mean the heading element?

Could you share what's logged in the console? I'm trying this in Chrome and what the browser is giving us in the clipboard is text without the heading, so we just look at that.

Is this a regression? Did it not always behave like this?

[danielbachhuber]

With formatting, you mean the heading element?

@ellatrix Yes.

Could you share what's logged in the console? I'm trying this in Chrome and what the browser is giving us in the clipboard is text without the heading, so we just look at that.

CleanShot.2023-02-20.at.04.39.39.mp4

Is this a regression? Did it not always behave like this?

Yes, it's a regression.

Interestingly, 'Copy block' seems to work fine:

CleanShot.2023-02-20.at.04.43.23.mp4

Maybe something changed about what the browser sees as selected?

[ndiego]

@danielbachhuber I was just testing this in WordPress 6.1.1 without Gutenberg, and the behavior appears to be the same. So while I agree that this is not the ideal behavior, I am not sure it's actually a regression. Would you be able to confirm on your end?

I'm just trying to whittle down the "Todos" for 6.2 as we prep for Beta 3, so if this is not a regression between 6.1 and 6.2, I recommend we punt to 6.3. Thanks!

[danielbachhuber]

I was just testing this in WordPress 6.1.1 without Gutenberg, and the behavior appears to be the same.

@ndiego I can confirm the same error occurs in WordPress 6.1.1.

So while I agree that this is not the ideal behavior, I am not sure it's actually a regression. [...] I'm just trying to whittle down the "Todos" for 6.2 as we prep for Beta 3, so if this is not a regression between 6.1 and 6.2, I recommend we punt to 6.3.

Regardless of the semantics, it seems like a pretty glaring bug to leave unfixed for a full cycle.

[ndiego]

Regardless of the semantics, it seems like a pretty glaring bug to leave unfixed for a full cycle.

100% agree, it would be great to get it fixed in time. I'm just concerned with the amount of other issues currently on the board. It does appear that this issue has existed at least as far back as 5.9. cc @annezazu

[danielbachhuber]

It does appear that this issue has existed at least as far back as 5.9.

@ndiego It stopped working more recently than 5.9, so maybe it's a change in browser behavior?

[annezazu]

Noting that I can replicate this with 6.3 beta 4. For further sleuthing, I noticed if I use the three dot menu > copy, it works. But if I select and copy, it doesn't:

heading.dependent.mov

[csabarakasz]

A user is reporting the same thing. They used to edit the post in Words and then paste the content into the Post Editor, and the formatting translated well. Based on their report, it stopped working. After pasting the text loses all previous formatting.

[ndiego]

A user is reporting the same thing. They used to edit the post in Words and then paste the content into the Post Editor, and the formatting translated well. Based on their report, it stopped working. After pasting the text loses all previous formatting.

Copy and pasting from other applications into the Editor should still work in most cases, so long as the copied text was actually a heading. If not @csabarakasz would you be able to report an issue?

This issue refers to copying a Heading within the Editor and then the formatting is lost. Given that this is not a new issue in 6.3, I recommend we punt unless anyone thinks we will be able to get a PR put together in time. Based on the discussion in the PR, which has already been punted, it seems quite tricky, but I defer to @ellatrix

[tellthemachines]

This issue is already present in 6.2 and we're in RC phase for 6.3 so let's leave it out for now.

[t-hamano]

In my Windows environment, Firefox does not seem to have solved this problem.

If I copy all the text in a heading block and paste it into an empty paragraph, the text appears to have been copied correctly, but the block remains a paragraph block. It also appears that the heading element is nested in the block itself.

Could you please re-test this issue to see if it works correctly in all browsers on MacOS?

Also, #48254 seems to have created a new problem with #53422.

8b8a73ca4869937a33d78e572950aed5.mp4

[stokesman]

On macOS, I tested in Chrome, Safari, Orion and Firefox and in each the behavior works as intended by #48254. A heading is inserted to replace to the empty paragraph.

However, I'm not sure this feels entirely right or of much value. If I copy/cut just a portion of a headline and paste it into a non-empty paragraph then it splits and I get a headline after the paragraph. It’s not a heavy lift to merge blocks after that (or avoid the split by pasting with cmd+shift+V) but the behavior doesn’t seem correct in such instances. As for its value in general—if I want a duplicate headline—I duplicate the block and I wouldn't miss this feature.

If this really is a regression and must be fixed, it seems it would be worth tracking down how it broke and how it worked before. For now, given the issue Aki raised, I'd lean toward reverting #48254.

[t-hamano]

Personally, I find it strange that when I paste copied text, the formatting (in this case, the heading element) is also pasted.

I expect that when text is copied, only the selected text and the inline formatting within it will be copied. Therefore, when I copy the entire text of a heading block and paste it into an empty paragraph, the expected behavior for me is that it will remain a paragraph and not be converted to a heading.

If you want to copy the block itself, you can press Ctrl + C with no text selected or select "Copy" from the block toolbar.

[richtabor]

Therefore, when I copy the entire text of a heading block and paste it into an empty paragraph, the expected behavior for me is that it will remain a paragraph and not be converted to a heading.

From a writing UX perspective, inline formatting and heading levels should be treated the same. The idea that these are separate "blocks" doesn't need to be expressed technically.

If you copy a heading and paste it somewhere else — it should remain a heading. If I copy a heading and paste it within a paragraph block that has content already, then I'd expect it to be added to the content as paragraph text within that block.

This is how Google docs works for example. It even goes one step further, maintaining the heading font size when you paste into a paragraph (but I don't feel that's necessary).

If you want to copy the block itself, you can press Ctrl + C with no text selected or select "Copy" from the block toolbar.

Copying should work the same, however it's copied (again, from the writing UX perspective).

[ellatrix]

For me, Firefox seems to behave fine. I'm not seeing the nested heading in a paragraph issue.

I do agree that we need some more fine tuning here. For example:

• When I copy a heading (regardless of how it's copied
  • Pasting it in an empty paragraph should preserve the heading.
  • Pasting it inside paragraph text should paste it inline? (Currently it splits the paragraph and inserts a heading in between.)

Would you agree?

[ellatrix]

Btw, I've added support for Firefox e2e test for paste in #53482.

[stokesman]

I just tested each minor from 6.0 to 5.3 and none of them copy/paste the Heading as formatting. This doesn't appear to be a regression and thus changing it is an "enhancement". Side note: it’s awesome how quickly wp-now allows testing those but I ran into failures with <5.3.

There is probably an agreeable compromise that can be made here, though in my view, the way it was before doesn't need changing. It's easier to copy the whole block with two existing methods than to select its whole content to do so.

• When I copy a heading (regardless of how it's copied

I think the state of the selection when copied is the key thing to consider. If the selection is the whole content of the block, that’s okay to treat as "copy the block". If the content is partially selected then treat it as "copy the content". Doing that means pasting should take care of itself, right?

[richtabor]

Pasting it in an empty paragraph should preserve the heading.

Yes.

Pasting it inside paragraph text should paste it inline? (Currently it splits the paragraph and inserts a heading in between.)

Yes, that's what this issue covers: #53076

[t-hamano]

Okay, I have summarized how it behaves in MS-Word and Google Docs.

MS-Word

• Copy all text in the heading and..
  • Paste into an empty paragraph: A heading with the same text is created
  • Paste after a paragraph with text: The paragraph and copied text are combined to form a heading
• Copy some text from the heading and..
  • Paste into an empty paragraph: Pasted as a paragraph
  • Paste after a paragraph with text: Text is added after the existing text in the paragraph

Google Docs

• Copy all text in the heading and..
  • Paste into an empty paragraph: A heading with the same text is created.
  • Paste after a paragraph with text: Text with the same font size as the heading is added after the paragraph
• Copy some text from the heading and..
  • Paste into an empty paragraph: Pasted as a heading
  • Paste after a paragraph with text: Text with the same font size as the heading is added after the paragraph

Given these factors, what would be the ideal behavior?

[annezazu]

Moving this out of the 6.4 board as we're in the beta cycle and only bugs related to this release can be addressed at this stage.

[bph]

There is a PR attached to this issue

• Rich text: copy tag name on internal paste #48254 that was merged for GB milestone 16.5.

@danielbachhuber does this fix the issue? If yes, we could probably close this issue as completed...

[ellatrix]

It was reverted

[annezazu]

Punting this as no work has been done and we're closing in on crunch time for beta 1 for 6.5.

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.