Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pasting text adds leading and trailing spaces #16172

Closed
galbaras opened this issue Jun 14, 2019 · 66 comments · Fixed by #19043
Closed

Pasting text adds leading and trailing spaces #16172

galbaras opened this issue Jun 14, 2019 · 66 comments · Fixed by #19043
Assignees
Labels
[Feature] Paste Needs Testing Needs further testing to be confirmed.

Comments

@galbaras
Copy link

Describe the bug
When copying some text and then pasting it into a block, it is pasted with a space before and a space after with the normal Windows Paste operation.

When using PureText to paste a text-only version of the clipboard, no leading or trailing spaces are added.

To reproduce
Steps to reproduce the behavior:

  1. Mark a word in a block
  2. Click Ctrl-C
  3. Put the text cursor at the end of the text
  4. Click Ctrl-V

Expected behavior
Exact copy of text pasted.

Desktop (please complete the following information):

  • OS: Windows 10
  • Browser: chrome
  • Version: 74.0.3729.169

Additional context

  • WP 5.2.1
@swissspidy swissspidy added [Feature] Paste Needs Testing Needs further testing to be confirmed. labels Jun 14, 2019
@kerilynnengel
Copy link

kerilynnengel commented Aug 22, 2019

This is happening to me to, every time, and makes editing a big hassle. Steps to reproduce listed above will always result in an extra space before and after the pasted text. This happens for any length of text within a block (words or complete sentences).

Operating System Windows 10 64-bit
Browser Chrome 76.0.3809.100

WP Version 5.2.2

@talldan
Copy link
Contributor

talldan commented Sep 3, 2019

I'm unable to reproduce this issue when checked out to the latest version of the editor in my development environment (master at f198997).

@galbaras
Copy link
Author

galbaras commented Sep 3, 2019

It doesn't seem to happen in a classic block, but it does in a paragraph block and list block, so please check those (there may be others).

When I test copying and pasting between Classic and List blocks, the difference is in the pasting operation, not the copying, i.e. the contents of the clipboard are correct. In fact, I can confirm this using a clipboard application.

@talldan
Copy link
Contributor

talldan commented Sep 3, 2019

@galbaras I didn't mean to sound dismissive of your original report, sorry if that's how it came across. WordPress 5.2.2 is running the equivalent I think of v5.3 of the Gutenberg plugin. The plugin itself though is now on v6.4 (and soon v6.5), so there have been lots of changes and bug fixes in the code base. I'm trying to establish whether it has been fixed in more recent versions.

If you're able to test with the Gutenberg plugin installed and activated that would be useful. Here's a demo of my test:

pasting

@galbaras
Copy link
Author

galbaras commented Sep 4, 2019

I didn't take your reply as dismissive. You'd need to replicate the problem in order to help.

Your capture looks good, but...

I've installed Gutenberg 6.4 and tested. The problem is still there. I can confirm that the scripts on the editor page were those of the plugin while I tested.

If this is fixed in 6.5, I can test again. However, can you please take a look at the code for pasting text and compare Classic with, say, Paragraph? That may help isolate the problem.

Sorry, I'm no good with React, so can't help :(

@mrfatguy
Copy link

mrfatguy commented Sep 19, 2019

Nope, not at all! :| I have just manually force-installed the development version of Gutenberg:

  • Version: 6.5.0
  • Last updated: 1 day ago

over production version of Gutenberg in my Wordpress 5.2.3. And either the development version was ignored / overloaded (after network activation of the plugin) by build-in production version of Gutenberg or the issue is still not fixed in Gutenberg 6.5.0.

Anyway, I still see these two damn surrounding spaces around each pasted text.

@nicpelletier
Copy link

This bug is in effect in the current Gutenberg version (6.5).

@mrfatguy
Copy link

What do you mean by "in effect"? Is it fixed? Is it still not fixed in G6.5 or what? :>

@nicpelletier
Copy link

The bug made it to the production version. It is still there. Sorry, english is a second language for me...

@mrfatguy
Copy link

Thank you. Now, everything is clear! :> So, we're still waiting for the fix.

No worries, we are all making mistakes. And that makes our lives really interesting. All the best to you.

@mrfatguy
Copy link

Sorry, to say this, but I find this feature extremely annoying. I am moving a lot of texts between many sources, so copy-paste is the key operation for me in Gutenberg. The fact that I have to stop and manually remove trailing and ending space with each and every paste influences performance of my work very negatively.

This is an important bug (appears in many scenarios and affects most of, if not all of Gutenberg users). Yet it should be very small to fix -- an addition of training and ending space during is a very unusual, artificial operation, so narrowing the responsible piece of code shouldn't be a problem.

Can we have any estimate when this will be fixed?

@ellatrix
Copy link
Member

@trejder Are you also on Windows?

@mrfatguy
Copy link

@ellatrix Yes! :>

@michaelbruetsch
Copy link

Am I the only one who has an even bigger problem with pasting? For me Gutenberg adds additional spaces completely randomly. Randomly meaning, while pasting the same text always at the same positions, but with (for me at least) no logical reason why exactly at those positions.

I double checked and there are no double spaces in the source text.

The exact same text pasted into the Classic element (within Gutenberg): No spaces. See here an example:

Gutenberg-Paste-Bug

PS: Sorry if this isn't helpful, first time posting here ;-)

@mrfatguy
Copy link

Since we're talking about editor that produces texts for website / blogs (where double spaces and all white characters are ignored) I think that the solution for problems all of us called up here would be a simple code that replaces all double spaces into single ones when pasting.

@nicpelletier
Copy link

Am I the only one who has an even bigger problem with pasting? For me Gutenberg adds additional spaces completely randomly. Randomly meaning, while pasting the same text always at the same positions, but with (for me at least) no logical reason why exactly at those positions.

I double checked and there are no double spaces in the source text.

I've seen that in pasts versions of Gutenberg. @michaelbruetsch What version are you using?

@michaelbruetsch
Copy link

@nicpelletier I'm using the current WordPress version 5.2.4. I read in this thread that WP uses a different version than the Gutenberg plugin itself here. So maybe that will be already fixed with the coming 5.3 update? Maybe I'm wrong in this thread. As I said, I'm new here ;-)

@mrfatguy
Copy link

I don't know how about @michaelbruetsch and pasting double spaces in random places. But, for the initial entry -- adding spaces in the beginning and end of each pasted text -- nothing changed so far.

I have just updated to the newest stable / production version of Gutenberg 6.7.0 and still spaces are being added as you paste any text.

@mrfatguy
Copy link

mrfatguy commented Nov 4, 2019

Do we have any priorities for bugs and functionalities in Gutenberg development?

Yesterday an update to Gutenberg inside Wordpress was released (version 6.7.0) and some breath-taking functionalities (sarcasm intended) like gradients in blocks were added. Yet, still no resolution on something as stupid (and in the same time affecting millions) as adding spaces when pasting text.

Any estimate when can this bug be taken into consideration by the dev team?

@mrfatguy mrfatguy mentioned this issue Nov 4, 2019
22 tasks
@talldan
Copy link
Contributor

talldan commented Nov 5, 2019

@trejder Please note that there's an etiquette guide - https://wordpress.org/about/etiquette/ - it specifically mentions unwelcoming behaviour. We're all smart enough here to understand what your sarcasm means, and it's not acceptable.

Please be professional in future. I understand you desperately want to raise the profile of this bug and that it's important to you, but it's just as important that you're respectful to those who work hard and contribute to this project—after all, they're the ones who you want to encourage to help solve this.

@mrfatguy
Copy link

mrfatguy commented Nov 5, 2019

Thank you for pointing out that my behaviour and wording may not be acceptable by some. True apologies for those that felt offended.

Yet, case remains unanswered. Are there any priorities, severity levels etc. or other ways or tools to rise awareness over a bug affected by most likely every user of Gutenberg and bring it closer to the resolution than some fancy new functionalities?

Are there any ways to estimate, at least at highest level when and who can take over this particular issue? After all we are talking about a bug which resolution should take less than a half an hour (plus testing), because it only covers a tiny pasting functionality (my unconfirmed, possibly wrong assumptions).

If any, be it internal or public, roadmaps, priorities etc. suggest that fix to this tiny, yet very painful bug is like months away in front of us (because team is occupied with adding new functionalities rather than fixing obvious bugs) then many of us will surely decide to give Gutenberg go. I don't imagine working with (otherwise perfect) editor which causes me to get a near-to-heartbreak state 300 times per hour, each time I am pasting some text.

@yankiara
Copy link

yankiara commented Nov 6, 2019

Am I the only one who has an even bigger problem with pasting? For me Gutenberg adds additional spaces completely randomly. Randomly meaning, while pasting the same text always at the same positions, but with (for me at least) no logical reason why exactly at those positions.

@michaelbruetsch Same problem here, WP 5.2.4 :-(

@talldan
Copy link
Contributor

talldan commented Nov 7, 2019

Are there any priorities, severity levels etc. or other ways or tools to rise awareness over a bug affected by most likely every user of Gutenberg and bring it closer to the resolution than some fancy new functionalities?

As you probably know, this is an open source project, so we rely on contributions. The hard part is that there are a lot of people creating issues, but only a limited number of people helping to organise/triage those issues. It's unfortunate that there weren't more responses to the Needs Testing label on this issue (not for over two months), as those responses would have helped bring this to attention.

Anyway, I've done some digging and I think there are two separate issues related to the way different browsers and operating systems handle pasting.


Issue 1

When copy/pasting from another web page on Firefox (both in Windows and Mac OS X) it's noticeable that there are extra spaces within the text that occur exactly where the html from the event's clipboardData wraps. In Chrome, this wrapping isn't present so the issue doesn't occur:

Clipboard value from JS paste event
Screen Shot 2019-11-07 at 11 18 55 am

Text in paragraph block
Screen Shot 2019-11-07 at 11 19 18 am


Issue 2

When copy/pasting text on Windows, the HTML from the clipboard event has new lines \n within it, which aren't removed by any of the filtering the editor does. I think this is where the spaces the OP mentioned come from.

This happens in Firefox and Chrome on Windows (haven't tested Edge or IE11, but I assume it's the same)—note the new lines next to the html and body tags which don't occur on a Mac:

Firefox, Windows
Screen Shot 2019-11-07 at 12 17 30 pm

Chrome, Windows
Screen Shot 2019-11-07 at 12 18 30 pm

Firefox, Mac OS
Screen Shot 2019-11-07 at 12 20 45 pm

Chrome, Mac OS
Screen Shot 2019-11-07 at 12 19 17 pm

@galbaras
Copy link
Author

galbaras commented Nov 7, 2019

The block editor is exciting to develop, and much less exciting to support, so thank you, @talldan , for taking the time and analysing.

What would you suggest? By "which aren't removed by any of the filtering the editor does", I'm guessing you meant "currently". Is this a matter of adding some filtering before adding the text to the block?

@talldan
Copy link
Contributor

talldan commented Nov 7, 2019

What would you suggest? By "which aren't removed by any of the filtering the editor does", I'm guessing you meant "currently". Is this a matter of adding some filtering before adding the text to the block?

I think I have an idea on how to fix the second issue. It looks like stripping out the new lines that are outside of those <!--StartFragment--> and <!--EndFragment--> comments, where they exist, should resolve that. I think it could be done in a fairly browser/platform agnostic way. I'll work on a pull request.

The first one seems trickier, as there are potentially cases where newlines should be preserved in pasted text. @ellatrix might know more on how it works.

@mrfatguy
Copy link

mrfatguy commented Nov 7, 2019

Thank you @talldan for providing such a great review of this issue. However, there's one thing that I must correct (emphasis mine):

When copy/pasting from another web page on Firefox (both in Windows and Mac OS X) it's noticeable that there are extra spaces within the text that occur exactly where the html from the event's clipboardData wraps. In Chrome, this wrapping isn't present so the issue doesn't occur.

The above statement is not true, at least not in my environment (Chrome 78 + Windows 10 Pro), where this issue does exist and is observable by me with every text paste into Gutenberg.

I have just performed a quick test of pasting text into Gutenberg editor from:

  • another Gutenberg editor (editing two articles in paralel),
  • GitHub (part your above sentence),
  • Gmail (some example message).

In all three cases the issue could be observed. All three pieces of text, even though carefully selected to not have any space in the beginning and in the end and though copied in the middle of the text, were pasted with spaces surrounding them.

Before pasting:

01

After pasting:

02

@galbaras
Copy link
Author

Maybe too late, but just in case, this is for copying and pasting the word "become" in a paragraph block:

Received HTML:

 <html>
<body>
<!--StartFragment--><span style="color: rgb(25, 30, 35); font-family: &quot;Noto Serif&quot;; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: pre-wrap; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">become</span><!--EndFragment-->
</body>
</html>
11:41:05.777 rich-text.min.js?ver=3.7.2:6 Received plain text:

 become
11:41:05.785 blocks.min.js?ver=6.7.2:2 Processed inline HTML:

 

become

@ellatrix
Copy link
Member

@galbaras That case should be fixed now and the fix will be in Gutenberg 7.2.

@mrfatguy
Copy link

@ellatrix Why you're closing a ticket, if you said for yourself that "that #19043 fixes some of the issues described here"? What about issues that remains unfixed? How they're going to be fixed, if ticket reporting them is closed?

@mrfatguy
Copy link

Adding console dumps in step-by-step process of copying and pasting example piece of text from Visual Editor into Visual Editor.

Step 1. Page / Visual Editor load on some draft article:

JQMIGRATE: Migrate is installed, version 1.4.1
index.js?ver=ffee04a5c015601fa7840a747e107e8b:1 wp.editor.InspectorControls is deprecated. Please use wp.blockEditor.InspectorControls instead.
c @ index.js?ver=ffee04a5c015601fa7840a747e107e8b:1
index.js?ver=ffee04a5c015601fa7840a747e107e8b:1 wp.editor.PlainText is deprecated. Please use wp.blockEditor.PlainText instead.

Step 2. Selecting and copying sometimes used by non-developers, text (unformatted, so looks the same in Code Editor):

index.js?ver=ffee04a5c015601fa7840a747e107e8b:1 `wp.data.select( 'core/editor' ).getSelectedBlock` is deprecated. Please use `wp.data.select( 'core/block-editor' ).getSelectedBlock` instead.
c @ index.js?ver=ffee04a5c015601fa7840a747e107e8b:1
(anonymous) @ index.js?ver=048001dcf6f0304c9176abd5f3efa063:11
e @ index.js?ver=1797bf8784ed2f6cc0feedc1ac56d5dd:1
(anonymous) @ index.js?ver=1797bf8784ed2f6cc0feedc1ac56d5dd:1
r @ index.js?ver=1797bf8784ed2f6cc0feedc1ac56d5dd:1
(anonymous) @ common.min.js?ver=20191211:1
(anonymous) @ index.js?ver=1797bf8784ed2f6cc0feedc1ac56d5dd:1
_t @ index.js?ver=1797bf8784ed2f6cc0feedc1ac56d5dd:1
(anonymous) @ index.js?ver=1797bf8784ed2f6cc0feedc1ac56d5dd:1
je @ react-dom.min.b694e242.js?ver=16.9.0:78
ph @ react-dom.min.b694e242.js?ver=16.9.0:215
lh @ react-dom.min.b694e242.js?ver=16.9.0:126
O @ react-dom.min.b694e242.js?ver=16.9.0:121
ze @ react-dom.min.b694e242.js?ver=16.9.0:118
(anonymous) @ react-dom.min.b694e242.js?ver=16.9.0:53
unstable_runWithPriority @ react.min.0212dc62.js?ver=16.9.0:26
Ma @ react-dom.min.b694e242.js?ver=16.9.0:52
mg @ react-dom.min.b694e242.js?ver=16.9.0:52
V @ react-dom.min.b694e242.js?ver=16.9.0:52
Be @ react-dom.min.b694e242.js?ver=16.9.0:119
xi @ react-dom.min.b694e242.js?ver=16.9.0:39
index.js?ver=ffee04a5c015601fa7840a747e107e8b:1 wp.editor.RichTextToolbarButton is deprecated. Please use wp.blockEditor.RichTextToolbarButton instead.

Step 3. Pasting above copied text into some other place (new paragraph at the end of text) in Visual Editor.

Getting sometimes used by non-developers, in Visual Editor (with surrounding two spaces).

Received HTML:

 <html>
<body>
<!--StartFragment--><span style="color: rgb(25, 30, 35); font-family: &quot;Noto Serif&quot;; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: pre-wrap; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">sometimes used by non-developers,</span><!--EndFragment-->
</body>
</html>
index.js?ver=7c6c2221add49d82b0166792f2b184c4:6 Received plain text:

 sometimes used by non-developers,
index.js?ver=4a81ccc4ccb8f6c45e1b07eaec152198:2 Processed inline HTML:

 

sometimes used by non-developers,

I maybe missing something, but it seems that console dump logs in both cases a text without any surrounding spaces in both Received HTML and Processed inline HTML. It only gets spaces added in Received plain text.

Please, reopen the ticket. Reported issue is not solved in Gutenberg 7.0. Thank you.

@ellatrix
Copy link
Member

@trejder have you tried #19043? The original reported issue is fixed. If you have any remaining issues after #19043, please create a new report.

@mrfatguy
Copy link

@ellatrix thank you. How can I test / check #19043 on my side? It doesn't seems to be included in Gutenberg 7.0 production. Shall I fetch dev code, overwrite production code with it and see, if the issue is resolved?

And even, if yes, then what? Shall I revert back to production? Is there any plan, in which production version of Gutenberg #19043 will be released?

@talldan
Copy link
Contributor

talldan commented Dec 12, 2019

@trejder One way I think you should be able to test without going through all those steps is using the block editor in the playground:
https://wordpress.github.io/gutenberg/?path=/story/playground-block-editor--default

This is a stripped-down version of the block editor which is missing some functionality, but the copy/paste handling should be the same as in the plugin and WordPress core.

The playground is updated every time a pull request is merged, so it has all the latest fixes, including #19043.

@gaelgerard
Copy link

Thanks for the tip @talldan !

And I can confirm, on this playground I can paste long texts without any extra space appearing.

👏 Good Game @ellatrix for the bug fix 💪

Do you know when it will be part of WP core version?

@mrfatguy
Copy link

@talldan Thank you!

@ellatrix Confirmed. Works fine and ready to go. The question remains -- when #19043 is planned to be released to the wild world (production version)?

@ellatrix
Copy link
Member

ellatrix commented Dec 16, 2019

It will be in the next Gutenberg plugin version, 7.2.0 I think, and the next WP release, 5.4 I believe.

@xpil
Copy link

xpil commented Jan 16, 2020

So annoying. And still there mid Jan 2020, almost half a year since when the issue was raised. Any chances for a fix before the next ice age?

@Coxxs
Copy link

Coxxs commented Jan 16, 2020

Gutenberg 7.2 has fixed the issue: https://wordpress.org/plugins/gutenberg/

@mrfatguy
Copy link

Seems true. I have just updated to Gutenberg 7.2 and it seems that I finally cannot reproduce this issue anymore. Thank you, t h a n k y o u, THANK YOU !!!

@xpil
Copy link

xpil commented Jan 17, 2020

Gutenberg 7.2 has fixed the issue: https://wordpress.org/plugins/gutenberg/

Indeed it has, thank a million! My blogging life suddenly became slightly less annoying ;)

@YukinoHayakawa
Copy link

Gutenberg 7.2 has fixed the issue: https://wordpress.org/plugins/gutenberg/

In the current version 7.5, the old leading and trailing spaces problem doesn't appear. However, it seems to be solving it by merely trimming the pasted text. Doing so causes pasting spaces to be impossible. I would say this is still a buggy behavior.

@xpil
Copy link

xpil commented Feb 16, 2020

Gutenberg 7.2 has fixed the issue: https://wordpress.org/plugins/gutenberg/

In the current version 7.5, the old leading and trailing spaces problem doesn't appear. However, it seems to be solving it by merely trimming the pasted text. Doing so causes pasting spaces to be impossible. I would say this is still a buggy behavior.

Agreed. But it's the lesser evil. In most cases I copy-paste stuff without leading/trailing spaces.

@mrfatguy
Copy link

On contrary to xpil, I disagree. If something is adding spaces (during copy) in front and in back of copied text (where original text does not include them) then solution by no means should be to stop that thing from adding these spaces rather than stripping spaces. This is up-side down solution, unfortunately.

@xpil
Copy link

xpil commented Feb 16, 2020

On contrary to xpil, I disagree. If something is adding spaces (during copy) in front and in back of copied text (where original text does not include them) then solution by no means should be to stop that thing from adding these spaces rather than stripping spaces. This is up-side down solution, unfortunately.

Again, I agree on the principle. It's better to fix a bug at source rather than blanketing it with an extra operation. No doubts here.

But.

For me as the end-user it's more important to use a feature that works correctly in 99% cases than to have a permanently broken one. End-users don't care about internals as long as they get the right outputs.

@mrfatguy
Copy link

With that clarification I can't do anything else than agree with you.

I think that we may safely assume that there are approx. 90-95% of users not having spaces around copied text and only 5-10% intentionally coping text with spaces in the beginning or end.

@YukinoHayakawa
Copy link

I think that we may safely assume that there are approx. 90-95% of users not having spaces around copied text and only 5-10% intentionally copying text with spaces in the beginning or end.

For me as the end-user it's more important to use a feature that works correctly in 99% cases than to have a permanently broken one. End-users don't care about internals as long as they get the right outputs.

I agree that the current behavior is less bad than before, simply because adding spaces is easier than moving the cursor and removing them, not because it is a good solution. On the other hand, I can even argue for trimming the spaces: selecting a word by double-clicking also selects the trailing space which is usually unwanted and trimming removes it, which is good. But both behaviors break a fundamental user interaction principle: The software should do exactly what it is supposed to do. In this case, it is pasting exactly what the user has copied. For this kind of basic operation it is supposed to be 100% correct in all cases for 100% users. It took me quite a while to realize that it wasn't me who copied extra spaces around the sentences, but the software who was making them.

@galbaras
Copy link
Author

galbaras commented Feb 16, 2020

The problem seems to be unrelated to the Gutenberg code. The browser is passing padded text to Gutenberg, by which time, the only course of action is either to remove them or to leave them.

Also, if you look above, you'll see that I've checked the copied text in the Windows clipboard and it appeared to be correct.

Removing is likely to provide better user experience than keeping the extra spaces.

Not sure if this is any help, @talldan & @ellatrix , but looking back at our communication, I see that this only happens when pasting formatted text, not plain text, and there seems to be a clear difference between the Classic block and others.

Can you confirm there's no other option here that will get us to 100%?

@talldan
Copy link
Contributor

talldan commented Feb 17, 2020

@YukinoHayakawa I noticed this even happens when copying from one paragraph block and pasting into another.

My feeling is that what's pasted should be as close as possible to what was copied. Would you be willing to open a new issue for this?

@talldan
Copy link
Contributor

talldan commented Feb 19, 2020

I've opened #20310, would be great to add any further comments there.

@YukinoHayakawa
Copy link

I've opened #20310, would be great to add any further comments there.

Appreciate your help in opening the new issue thread very much. I was hesitating about how to describe the problem in a good way.

@getdave
Copy link
Contributor

getdave commented Oct 6, 2021

Following up here that this seems similar to the fix that when into #33607 in 11.4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Paste Needs Testing Needs further testing to be confirmed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.