Pasting text containing brackets with Ctrl+Shift+V changes text into an incorrect link / URL instead of pasting "a is"

[pansamolot]

Description

When you paste a text using Ctrl+Shift+V then it is expected that it will be pasted unconditionally as a plain-text. Yet, when you paste this way a piece of text that contains a lot of square and regular brackets, i.e.:

[N1--13]([N-5,4]-[N-8,2]-[N-11,2])

then you always gets this as an incorrect (not working) URL. There's no way to paste such string into Gutenberg.

Step-by-step reproduction instructions

1. Start a new post. Create a new Paragraph block
2. Copy any string similar to [N1--13]([N-5,4]-[N-8,2]-[N-11,2]) from any source
3. Paste it as plain text using context menu or Ctrl+Shift+V shortcut

Expected behaviour

Text is pasted as-is / as plain text.

Actual behaviour

Text is pasted as incorrect / not working URL.

Screenshots or screen recording (optional)

WordPress information

• WordPress version: 5.7.2
• Gutenberg version: 11.0.0
• Are all plugins except Gutenberg deactivated? No
• Are you using a default theme (e.g. Twenty Twenty-One)? No

Device information

• Device: Intel Dual Core i3-2310M CPU, 8 GB RAM, 64-bit, laptop**
• Operating system: Windows 10 Pro, 20H2 (19042.1083)
• Browser: Google Chrome 91.0.4472.124

[getdave]

Thanks for the report. Much appreciated.

I've been able to replicate this and the source of the issue is in

gutenberg/packages/blocks/src/api/raw-handling/paste-handler.js

Lines 133 to 135 in 5c5ff4d

	if ( ! /^\s+$/.test( plainText ) ) {
	HTML = markdownConverter( HTML );
	}

Essentially Gutenberg is trying to convert the plain text to markdown. When it does this the raw text that you provided is seen as the markdown hyperlink syntax which is why your text gets converted into a link.

I'm not entirely sure how best to fix this yet without breaking the existing functionality of auto-markdown conversion.

[getdave]

Perhaps @ellatrix you would be able to advise here? There's also the possibility it's been incorrectly matched as a shortcode by the paste hander as this is where the AUTO mode is set

gutenberg/packages/block-editor/src/components/rich-text/use-paste-handler.js

Lines 163 to 169 in 5c5ff4d

	if (
	mode === 'AUTO' &&
	isEmpty( value ) &&
	isShortcode( plainText )
	) {
	mode = 'BLOCKS';
	}

[getdave]

Confirmed setting __unstablePastePlainText={ true } on <RichText> disables the faulty behaviour. Could we force to true if the Cmd + Shift + V keyboard combo is active?

[pansamolot]

@getdave Is there any progress on this? Will there be any pull request / bug-fix to this, since it seems that you have identified the source of the problem quite precisely?

[getdave]

@pansamolot I'm afraid not. There's a number of competing priorities at the moment and so it's still open for anyone to pick up.

That doesn't mean I don't think it's important it's just I've been engaged elsewhere.

I will add to be list to try and get to it as soon as I can. I'll also raise in the next Core Editor chat to see if I can get some eyes on it.

[pansamolot]

@getdave Thank you! :>

[mrfoxtalbot]

This forums thread seems to be a different example of the same underlying issue and provides an interesting "real life" use-case:

In Germany there is a gender neutral writing method that makes use of the asterisk. E.g.: “Mitarbeiter*innen”. So words in a text may contain asterisks, and users should still be able to copy paste texts into Gutenberg that contain such formatted words.

Do we have something like a filter that would deactivate markdown parsing, @getdave? I get that this is not a priority but it could be a setting in the Editor preferences.

[getdave]

Not that I'm aware of sorry.

I think @ellatrix would be well placed to advise on whether we can add an exception for these rules or implement something akin to my previous suggestion.

[ellatrix]

Confirmed setting __unstablePastePlainText={ true } on <RichText> disables the faulty behaviour. Could we force to true if the Cmd + Shift + V keyboard combo is active?

We could try that

[getdave]

I tested this with the latest version of the editor and I could no longer replicate the bug describe.

Screen.Capture.on.2024-03-13.at.14-40-51.mp4

@pansamolot just letting you know that I'm going to close this issue but feel free to re-open if you can still replicate this.