Could this be related to T241889?

If "something" is generating extraneous trailing newlines during editing, but the parser eats them on save, you would get symptoms like this.

In T245154#5884091, @Xover wrote:

Could this be related to T241889?

If "something" is generating extraneous trailing newlines during editing, but the parser eats them on save, you would get symptoms like this.

Hmmm sounds like it. If the wikitext for the diff/preview is retrieved the same as for the conflict resolution then these issues might have the same cause.

Ok one thing I found out already: The reason why there are no newline differences in the diff of the core edit conflict solving screen is, that wikidiff2 is used for the diff there and it trims trailing newlines. If I use the PHP diff engine there we also see the "artificial" newlines in the code.

So the text that is used for the conflict does in any case contain these newlines the your version but no newlines in the stored version. ( as also could already be seen in the textareas of the core screen )

Change 572220 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/ProofreadPage@master] Rtrim input text

https://gerrit.wikimedia.org/r/572220

Change 572220 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Rtrim input text

https://gerrit.wikimedia.org/r/572220

Change 572286 had a related patch set uploaded (by Tpt; owner: Tpt):
[mediawiki/extensions/ProofreadPage@master] Revert "Rtrim input text"

https://gerrit.wikimedia.org/r/572286

@WMDE-Fisch @awight a significant set of users in Wikisource introduces lines jump at the beginning of the Page: pages body to introduce or not the new paragraph identation. This behavior has been broken for a small amount of time in the past and a significant amount of editors complained. Maybe removing line jumps is the good way to go, but this needs some thought in order to at least get an idea of the number of affected pages.

I just submitted a revert commit, please +2 it.

@Tpt rtrim() removes trailing whitespace only, so this shouldn't affect leading newlines in the body of the page, should it?

@Xover. Indeed, I should have read the code more carefully. The existing code seems to trim the line jumps at the end of the header and the line jumps at the end of the footer does not seem to be considered by the parser. So the change should not break anything hopefully. Sorry for the noise.

Change 572286 abandoned by Tpt:
Revert "Rtrim input text"

Reason:
I got confused by trim vs rtrim.

The change that got merged should not create the problem I feared.

For more background, please see https://phabricator.wikimedia.org/T245154#5885428

(sorry for the small description in the commit message and the noise)

https://gerrit.wikimedia.org/r/572286