I could fix the issue in T245154: Edit conflicts in the page namspace show unintended newlines in footer diff with https://gerrit.wikimedia.org/r/572220. - The patch might also be a valid fix for this problem here.

@WMDE-Fisch Doesn't this just hide the problem? These newlines are coming from somewhere, and I can't think of a valid reason for them, so the root cause really should be fixed imo.

Incidentally, anywhere you add such things it'd be really helpful for others reading the code after the fact if there was a comment explaining why non-obvious stuff like the rtrim() is there. If it's a workaround for a given Phab, then just something like "// rtrim() is needed to work around T 241889".

In T241889#5884626, @Xover wrote:

@WMDE-Fisch Doesn't this just hide the problem? These newlines are coming from somewhere, and I can't think of a valid reason for them, so the root cause really should be fixed imo.

Incidentally, anywhere you add such things it'd be really helpful for others reading the code after the fact if there was a comment explaining why non-obvious stuff like the rtrim() is there. If it's a workaround for a given Phab, then just something like "// rtrim() is needed to work around T 241889".

You're right, this needs more explanation. I very briefly tried to do that in the patch commit message, but it should probably also be in the code ( and I could extend the commit message):

All textboxes used on the edit page ( and also the three textboxes used by ProofreadPage [0] ) are build with the EditPage::showTextbox() method [1]. That method will add an "extra" empty line to the end of text in the editor[2]. As mentioned in the patch commit message this is done for convenience. Afaik it's assumed that it feels better to expand a text in a textbox at the bottom if there's an empty line you can start putting your cursor in to start writing.

This "artificial" empty line must at least be removed again when working with the text later. Furthermore it conceptually does not make sense to allow empty lines at the end of an article text ( and also not at the end of the header main or footer sections in ProofreadPage ) I would say. So even if there would be no "artificial" empty line make sense to trim any empty lines added by the user.

But like I've said the trimming should probably be done in a more transparent explanatory way. I'll see what I can do and what makes most sense. Thanks for your feedback here. :-)

[0] https://gerrit.wikimedia.org/g/mediawiki/extensions/ProofreadPage/+/d74f0ca26746492ddac0f1eefadab2ffb6db91c7/includes/Page/EditPagePage.php#142
[1] https://gerrit.wikimedia.org/g/mediawiki/core/+/f7f069936752d0c97d6266a6976a731bf3952ec4/includes/EditPage.php#3504
[2] https://gerrit.wikimedia.org/g/mediawiki/core/+/f7f069936752d0c97d6266a6976a731bf3952ec4/includes/EditPage.php#3514

The patch that solves the problem described in T245154: Edit conflicts in the page namspace show unintended newlines in footer diff got merged and was deployed to All-and-every-Wikisource yesterday. Could you please check if the issues is fixed now? Thanks! :-)

@WMDE-Fisch I tested it on a couple of pages where I have seen the issue before, and I do not see it now. I will post to the Scriptorium and let them know so that the whole community can test.

PS I think this ticket is a duplicate of T188844 ?

English Wikisource has been informed of the fix: https://en.wikisource.org/wiki/Wikisource:Scriptorium#Possibly_fixed%3A_the_newline_proliferation_issue_when_previewing_edits_in_Page_space

After testing, this appears to be resolved.