Collapsible items with WYSIWYG field always show as changed

Haven't tested but what comes to my mind is that when a text field is empty and you open it to display its value in a WYSIWYG, the WYSIWYG adds an empty

tag, maybe that's why it is always "changing"?

This smells like major inconsistency in core. I don't want to spent too much energy in workarounds.

If we can super quickly compare text after a newline normalization (simply compare after \r\n => \n) then fine.

But we need to identify why this ever is stored once with \n and then later provided with \r\n. This is wrong input data handling/conversion and we need to identify the related core issue or report this with high priority.

The diff project also contains some newline tricks to create line diffs that removes those conversion problems, but that's still a workaround and can even be confusing: why is my diff empty if it claims the value is different?

We're a content management system, we need stable content interaction and storage with the common variety of devices.

Except this isn't happening in Drupal, which is loading/storing \r\n just fine.

it's the input string from the browser that somehow changes as far as I see. Not sure why and where and why it is \r\n first and then not anymore later.

Fun stuff i found:

When the value is read through JavaScript rather than being submitted directly from a form, browser behaviour differs. IE and Opera return strings with CRLFs in; Firefox and WebKit return LF. So any form that gets submitted with JavaScript/XMLHttpRequest help is likely to come in either form.

https://stackoverflow.com/a/6324648

Could it be that it is sometimes an ajax submission and sometimes a regular form submit?

And a nice essay on thejs api mess
http://perfectionkills.com/the-poor-misunderstood-innerText/

yes, that's exactly what happens then I guess. The wysiwyg is either closed by default and closed and then in those cases the value is submitted through ajax requests.

Note: I don't experience this issue with default content from Paragraphs Collection + Chrome on Linux.
But as soon as i add new content, save, edit again and collapse (ajax post), it is marked as changed.

Is it possible that default content stores text as \n and user added text stores as \r\n while then ajax collapse converts to \n again?
That, however, would mean that we need to normalize our default content to \r\n as well and sure process ajax submission.

Unsure if we should apply a workaround for ajax with Paragraphs or wait until core establishes consistency. I guess it will take a long time.

Just wanted to point out that we there's a core issue which seems to handle the same problem described here: #2856801: AJAX form submission is not encoding new lines in textarea values as CRLF pairs, but only as LF - resulting into a different values than browser submission

Was talking to @amateescu about change tracking problems like this, he pointed out #2856801: AJAX form submission is not encoding new lines in textarea values as CRLF pairs, but only as LF - resulting into a different values than browser submission as basically a duplicate of this, which now is basically a duplicate of #2899141: jQuery Form Plugin update to latest stable release as it is apparently fixed in the latest version of jquery form...

I tested the core patch of the jQuery Form update and i still see these paragraphs changed...
https://www.drupal.org/files/issues/2899141-jq-form-5.patch

Well, I just tested the patch form #2899141 with 8.x-1.2 version of paragraphs module and it solves the problem.

@SylvainM That would be cool. What Browser did you use?

Firefox 58.0 (Linux)

Just tested in Chromium 63.0.3239.84 and the patch in #2899141: jQuery Form Plugin update to latest stable release works. There are no more changed icons after collapsing.

Just tested again in Firefox. It seems last time the patch was not properly applied. I used "curl LINK | git apply" and that sometimes silently does nothing at all...

So yeah, confirming that this does the job.

Postponing in favor of: #2899141: jQuery Form Plugin update to latest stable release.

As the core issue was committed this problem is solved now.

Except it isn't... This problem is back again.

Was this fix maybe reverted in jQuery with a more recent version?

I am also experiencing this issue. When I add a paragraph, then save the paragraph, Chrome warns: "Changes you made may not be saved" even though I am clicking save.