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

When a string of multiple "Space" characters is pasted, only one will be displayed #1751

Closed
Softvision-MariusComan opened this issue Oct 10, 2017 · 10 comments

Comments

@Softvision-MariusComan
Copy link

From: mozilla/notes#285

[Affected versions]:

  • Firefox Notes 1.8.0 rc5
  • Firefox 56 and up

[Affected Platforms]:

  • All Windows
  • All Mac
  • All Linux

[Prerequisites]:

  • Have a Firefox profile with the latest "Firefox Notes" add-on version (1.8.0 rc4) installed.

[Steps to reproduce]:

  1. Open the browser with the profiles from prerequisites.
  2. Write two characters with multiple "space" characters between them.
  3. Copy the string from step 2.
  4. Paste the string and observe it.

[Expected result]:

  • The pasted string is the same as the copied one.

[Actual result]:

  • Only one "space" character is displayed between the two other characters.

[Notes]:

  • If at step 2 you copied a similar string from a different source instead of writing it, the issue is no longer reproducible.
  • If you copy the string from step 2 and paste it to another text editor(e.g. the address bar, Google Docs, etc.) only one "space" character will be displayed between the other characters.
  • The issue is also reproducible with the TxP version of "Firefox Notes".
  • Attached a screen recording of the issue:
    space
@benbro
Copy link
Contributor

benbro commented Oct 10, 2017

Related:
#996
#1280

@LFDM
Copy link
Contributor

LFDM commented Oct 12, 2017

I can second this issue

I am currently using Quill through React Quill, which using pasting on its initial render to set the editor's contents ( https://github.com/zenoamaro/react-quill/blob/master/src/mixin.js#L68)

Quill is producing whitespace within HTML when you tab. Given the following example (* indicates the cursor position)

<p>*This is text</p>

hitting tab several times will produce something like this

<p>              *This is text</p>

Whenever we store this strong and try to re-instantiate in a React Quill instance, this text is pasted into Quill through the code line linked above.

matchText will eventually collapse this whitespace and ruin our string (https://github.com/quilljs/quill/blob/develop/modules/clipboard.js#L342)

I totally agree with @jhchen's explanation in #996 - it makes sense to have this collapsible behavior when pasting HTML, however in this case I just don't want to do that. I also own the string which I am pasting in and can guarantee that all the whitespace it has, should be preserved.

One possible solution I could see is to provide a flag for dangerouslyPasteHTML, which allows to preserve white-space - I am willing to provide a fix for this, if you as maintainers could live with this solution.

What do you think?

@jhchen
Copy link
Member

jhchen commented Oct 23, 2017

This issue specifically is caused by the same thing as #1752 so I'll close this as a duplicate.

To answer @LFDM's question: Quill makes use of this itself when it initializes wraps HTML in a <div class='ql-editor' style="white-space: normal;"> (see core/quill.js). So if you want to preserve whitespace set it to 'pre' which you can see from the if block from the code you pasted is what it is checking for. You may want to see if react-quill wants to accept a PR using this technique.

@Akitha
Copy link

Akitha commented Oct 8, 2018

Add this to styles.css

.ql-editor {
white-space: normal!important;
}

@benwinding
Copy link

Works for spaces, but this prevents the Tab key from working... any fixes for that?

@benwinding
Copy link

My problem was with ngx-quill, solved here: KillerCodeMonkey/ngx-quill#641 (comment)

@vkolotov
Copy link

For those who is still suffering from this nasty issue in 2021 O_o:

// this module is to workaround a nasty issue with preserving white spaces (they got stripped out):
// https://github.com/quilljs/quill/issues/1752
// https://github.com/quilljs/quill/issues/2459
// https://github.com/quilljs/quill/issues/1751
class PreserveWhiteSpace {
  constructor(private quill: any, private options: {}) {
    quill.container.style.whiteSpace = "pre-line";
  }
}
Quill.register('modules/preserveWhiteSpace', PreserveWhiteSpace);

Do not forget to add preserveWhiteSpace module in your quill, e.g.:

export const quillModulesBasic: Quill.StringMap = {
  imageResize: {
    modules: [ 'Resize', 'DisplaySize' ]
  },
  clickableLink: true,
  preserveWhiteSpace: true,
  toolbar: [
    ['bold', 'italic', 'underline', 'strike', 'blockquote'],
...

The root cause is in the quill.core.js module, specifically in the computeStyle function, for some unknown reason it does not return "whiteSpace" set to "pre-line" or "pre-wrap" (even if it is set in css). Which leads to matchText function to strip out white spaces:

image

@JamalSBS
Copy link

JamalSBS commented Nov 5, 2021

This issue specifically is caused by the same thing as #1752 so I'll close this as a duplicate.

To answer @LFDM's question: Quill makes use of this itself when it initializes wraps HTML in a <div class='ql-editor' style="white-space: normal;"> (see core/quill.js). So if you want to preserve whitespace set it to 'pre' which you can see from the if block from the code you pasted is what it is checking for. You may want to see if react-quill wants to accept a PR using this technique.

This solution that @jhchen alludes to completely breaks bullet lists and numbered lists in Quill. And it doesn't work if produced HTML is to be used in an email client.

@JamalSBS
Copy link

Add this to styles.css

.ql-editor {
white-space: normal!important;
}

And this solution prevents users with Firefox on Windows from adding spaces between a char or word entirely. No known workaround.

@benderillo
Copy link

#1751 (comment)
@vkolotov This solution worked well for me!
Thank you sir! And btw, it is the end of 2022 already but the problem is still there ;)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants