[Bug] WYSIWYG not saving correctly in draft mode

[adronitis]

• Laravel 8.21
• Twill 2.1.1

Translated WYSIWYG is not saving when clicking "Save as draft".

The only way to work around this is to double save with "Save as draft" or use the other save button or edit any other input field before clicking "Save as draft".

[pboivin]

Hey @adronitis,

I think I've been able to replicate this bug on Twill 2.1.1, as well as 2.3.1, but somewhat unreliably...

On my end, the bug happens regardless of draft or live status.

Steps to reproduce:

1. Fully refresh the page with the WYSIWYG field
2. Click directly in the field to bring focus to it and add some text
3. Click directly on the Update button
4. Fully refresh the page again

I get a standard browser warning about unsaved changes, but not reliably. Sometimes the save actually works and the refresh follows through normally.

Does that make any sense? Is this different to what you are describing?

[adronitis]

Indeed, following your steps I can reproduce the not saving issue. In addition, sometimes if the text is copied from a document (can be Google Doc or anything), then the issue also appears right away. The only way to make it workable again is to remove the block and re-add it again then paste the text without formatting.

However with your steps, if you do "Update and Close" sometimes it also works.

[pboivin]

Thanks for taking some time to test! I'll poke around the WYSIWYG source code over the next few days and report here :)

[ifox]

@pboi20 thanks for digging into this! The main issue seems similar #839. The issue mentioned with pasted content from Google Docs is more complex. We ran into it too, a few times. It produces an error in console from Quill which is basically not booting correctly on load, or crashing at runtime, preventing any further update to the field content. We've reported the issue: slab/parchment#87. There are very specific invisible characters causing this. We've went as far as adding a dynamic "fix WYSIWYG fields" button to the form sidebar for some of our clients that would sanitize that faulty content on demand from the backend and reload the page. Definitely not the solution we want to implement in Twill core.

[antonioribeiro]

@ifox , someone created a fix for it here, should we fork and apply it until Quill developers are able to fix it? That issue is sitting there for one year.

[ifox]

Oh, awesome! We don't need to fork Quill to leverage this, I believe.

[pboivin]

@ifox Thanks for the feedback! I see that the copy/pasting issue has been covered extensively in other threads. I'll focus on the main issue — WYSIWYG not saving reliably.

I'll take some more time to test but so far, I think this could be caused by the 600ms debounce on textUpdate: https://github.com/area17/twill/blob/2.x/frontend/js/components/Wysiwyg.vue#L236-L238

Looking at the vuex mutations, there is a difference between:

1. edit, wait, then click Update (left)
2. edit, then very quickly click Update (right)

I've been testing in light of this and can't seem to replicate the issue if I always make sure to wait > 600ms between edit and update.

@adronitis Does that fit with your experience of the issue? Is there anything else I'm missing?

[adronitis]

Nice, yes this fit what I was experiencing in the very beginning,. This could be the issue!

[ifox]

Closing as the OP issue has been fixed. The copy/paste issue should still be addressed separately to resolve #458.