All spaces converted to in quill-editor
We are using quill-editor in our application to create a resume. Since all spaces are converted to (non breaking space), the printable version created by LateX is broken (line doesn't break at the right space).
Reverting to 2.0.2 works.
Steps for Reproduction
- Use quill-editor in an application (angular) with the version 2.0.3
- Enter a string with spaces
- Verify the value of the input (all spaces are converted to )
Expected behavior:
Input: This is a test
Output: This is a test
Actual behavior:
Input: This is a test
Output: This&nbps;is&nbps;a&nbps;test
Platforms:
Angular application running on latest browser (tried safari, chrome, chromium, firefox)
Version:
The issue is located in this commit : https://github.com/slab/quill/commit/07b68c98b3bb61e6a6efb369a76f44a16b278517 where you can see line 374 :
return escapedText.replaceAll(' ', ' ');
Duplicated of https://github.com/slab/quill/issues/4509
Would like to see this fixed as well
Any updates?
We are reverting to 2.0.2 because this breaks our use cases. I can't imagine anyone wanting this change.
Glad someone else saw this - we're upgrading from Quill 1 to 2 and I saw this and was very confused. At least there's a minor version back that doesn't have the issue 🙃
In our own codebase we do HTML validation where we confirm certain behaviors end up creating a certain HTML - I wonder if Quill needs something like that
We reverted to v 2.0.2 to fix this issue. Will this be fixed?
Could this be something they added as Quill zaps all multiple spaces otherwise in v2.0.2? We have an issue where if you have two tags within each other, for example <em><var ...></var></em> - if the user presses space after this the spaces are added between the </var> and </em> and although they are retained and posted to our server correctly as well as being the actual value in the textarea from which quill is initialized from, it will remove those spaces because it considers them not needed. This causes words to be glued together. My thought about a fix for this is to convert these to - but perhaps they already did this and I need to upgrade to a new version.
EDIT: Whoa! I just upgraded to 2.0.3 and while this actually fixed our problem I see it introduced another where the text will no longer break if being rendered! does not have the same behaviour as a space with regards to normal word wrapping.
you can just add word-break: break-all; in tag.
So It will break line even with
Just updated and have to revert back again. This breaks the layout on a lot of pages. Sure this can be averted by word-break: break-all, but bad work arounds tend to break other stuff. Not worth it.
I also had to revert to 2.0.2 as I cannot easily work-around it with word-break - in my use case I send the text to an external CRM which also generates PDFs out of it, but now they become nearly unintelligible with the wrapping
Overwriting ctrl+c behaviour with ngx-quill :
<quill-editor (onEditorCreated)="editorCreate($event)">
editorCreate(quill:any) { quill.keyboard.addBinding({ key: 'c', shortKey: true }, function(range:any, context:any) { let html = quill.getSemanticHTML(range.index, range.length).replaceAll(' ', ' '); let plain = quill.getText(range.index, range.length); let blobHtml = new Blob([html], { type: "text/html" }); let blobText = new Blob([plain], { type: "text/plain" }); let clipboardItem = new ClipboardItem({ "text/html": blobHtml, "text/plain" : blobText}); navigator.clipboard.write([clipboardItem]); }); }
We are also affected by this
We're also affected, we use the text in a non-html world, so applying word-break: break-all; as some suggest is not an option :-/
We are also affected, and using ngx-quill so cannot easily revert to 2.0.2 quill version. Using temporary workaround while waiting for a fix :
On template
<quill-editor (onEditorCreated)="onEditorCreate($event)">
On component
onEditorCreated(quill) {
quill.legacyGetSemanticHTML = quill.getSemanticHTML;
quill.getSemanticHTML = (a: number, b: number) =>
quill
.legacyGetSemanticHTML(a, b)
.replaceAll(/((?: )*) /g, '$1 ');
}
We are also affected, and using ngx-quill so cannot easily revert to 2.0.2 quill version. Using temporary workaround while waiting for a fix :
On template
<quill-editor (onEditorCreated)="onEditorCreate($event)">
On component
onEditorCreated(quill) { quill.legacyGetSemanticHTML = quill.getSemanticHTML; quill.getSemanticHTML = (a: number, b: number) => quill .legacyGetSemanticHTML(a, b) .replaceAll(/((?: )*) /g, '$1 '); }
Can confirm, this works in the latest issue of Angular (19.2.5) with Quill 2.0.2 and ngx-quill 27.0.1.
The solution that worked for us:
Create a module
// src/patches/quill-nbsp-fix.ts
import Quill from 'quill';
(function installNbspFix() {
// Get the original method that *every* Quill instance inherits
const original = (Quill as any).prototype.getSemanticHTML;
// ugly patch to fix the issue with in Quill
(Quill as any).prototype.getSemanticHTML = function (
this: Quill, // explicit `this` for TS strict‑mode
index = 0,
length?: number
): string {
const len = length ?? this.getLength();
const html = original.call(this, index, len);
return html.replace(/ |\u00A0/g, ' ');
};
})();
Import it in the main.ts
import './app/_shared/patches/quill-nbsp-fix';
Specify the module in the editor:
<p-editor name="description" [modules]="{ nbspFix: true }" [(ngModel)]="model.description"></p-editor>
@byvernault Can you close this as a duplicate of https://github.com/slab/quill/issues/4509 ? That issue has links to PR's that fix this and has a regex that fixes this :)
This is the worst change I have ever encountered. This cost hours of figuring out why customer emails suddenly didn't format properly. To push a breaking change like this in a minor version from 2.0.2 to a 2.0.3 is insane.
I'm locking this package down in my code and never using this in future projects again.
edit: also this doesn't just add nbsp; but uses nasty unicode 00A0 as well? Even worse to detect and replace.
This is the worst change I have ever encountered. This cost hours of figuring out why customer emails suddenly didn't format properly. To push a breaking change like this in a minor version from 2.0.2 to a 2.0.3 is insane.
I'm locking this package down in my code and never using this in future projects again.
edit: also this doesn't just add nbsp; but uses nasty unicode 00A0 as well? Even worse to detect and replace.
Same scenario here. Pinning to 2.0.2 as well.
Terrible breaking change. Can't rely on this library in the future.