Writer: non-breaking spaces cause endless "Revert" state

[igregson]

Description

The exact issue I'm seeing is described here (in the issue it was suggested to the OP to create a GH issue but it seems he never did):

https://forum.getkirby.com/t/orange-bar-keeps-re-appearing-on-reverting-changes-in-panel/24271

I experienced the bug in Kirby v3 and am still experiencing it in Kirby v4.

It does not always happen. I have not yet been able to isolate what's needed to recreate it.

It happens often enough to be annoying and potentially quite confusing for users (e.g. resulting in not knowing if their changes were actually reverted).

Expected behavior

When clicking "revert" the "Revert" and "Save" buttons should disappear.

Your setup

Kirby Version
4.1.0

Your system (please complete the following information)

• Device: Mac Book
• OS: macOS
• Browser: Brave

[igregson]

I don't know if it's related, but I've noticed that ?language=null is appended to the key of each localstorage item (which seems to be used for tracking/persisting change state):

UPDATE: This does not seem related (I've just checked on a v3 site which also has this issue and the language query param is not on the key).

[afbora]

This issue was related to special characters. If you share the content file of the page you have the issue, maybe we can replicate the issue and find a solution.

[igregson]

This issue was related to special characters.

So it's a known issue?

Any further context to point to here (other issues, PRs) (I've looked but haven't been able to find any).

If you share the content file of the page you have the issue, maybe we can replicate the issue and find a solution.

Unfortunately it's within the context of a closed source project.

I'll try to create an isolated test case that reproduces it.

---

It's worth pointing out the following workaround (that suggests this isn't related to special chars in the content file):

1. On a page with the issue...
2. Reload the page (i.e. click the browser's "refresh" button)
3. Before making any content changes, click the "Revert" button
4. It works (no issue)

However, if you make changes before clicking the "Revert" button it does not work.

[igregson]

Found some context:

• Stuck in an unsaved changes loop #3798
• Solve update and revert issues in the writer #3758
• Compare JSON docs to avoid unsaved changes loop #3899

[igregson]

Alright, read through some of the past context and found the following:

• I'm only seeing the issue when changes are made inside a text block (i suppose any type of input field that uses prosemirror)
• The issue seems to be from   getting inserted (from pasted content). It's not visible in the editor. I've noticed these characters so far only between sentences when the author used double spaces between them.
• The site I'm seeing this on has lots of migrated content from a legacy WP site. There's lots of poorly formatted HTML that includes   in the plain text source.

[igregson]

Seems the primary PR that previously addressed this (#3758) was mostly around  .

I can reliably reproduce this by pasting HTML that contains   into a writer field instance.

So to reproduce:

1. Open a page with a writer field input
2. Paste html into it that contains   (tried to add this here but it seems GitHub's markdown handling strips it)
3. Save
4. Reload
5. Make a change in the field
6. Click the "Revert" button
7. Notice that the "Change" and "Save" buttons are still there

Question:

Is there any reason to preserve   instances in pasted text? GitHub seems to be stripping it.

Maybe the simplest "fix" is to replace all   instances with actual spaces on paste. To handle existing content in this state the same "replace" approach could be done on save (as a sanitization step).

[distantnative]

I could replicate it as described, @igregson, thanks.

What It seems to be:
After saving and reloading, our backend sends the field value with a normal space or actual non-breaking space (probably the latter, but not sure yet). But ProseMirror will return it after the input as  . So our content store is comparing those strings against each other and determine that they are not equal, though changed. This is why hitting "Revert" is not fixing it as there will still be the normal (non-breaking) space vs. the encoded &nbsp:.

[distantnative]

@bastianallgeier @lukasbestle How can we preserve &nbsp: when the text is processed by Parsley?

[lukasbestle]

TBH I can't really help here as I wasn't involved in the development of Parsley.

[distantnative]

@lukasbestle My mistake, I always mix up Parsley and Sane there.