This seems as a bug in proofread.js from the ProofReadPage extension. Moving it there.

P.S. you guys have an error in MediaWiki:Edittools, because one of the links links is not closed and causing invalid html. (The insert link after the DEFAULTSORT insertion.)

thomasV1 wrote:

I guess this a duplicate of bug 12130

*** This bug has been marked as a duplicate of bug 12130 ***

Here the line breaks are not in the beginning of the wikitext: they are after a <noinclude>...</noinclude> block.

Also, it just happens with javascript enabled, and only on Wikisources. For example, the same kind of edit on Wikipedia works normally:
http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&diff=prev&oldid=398057106

thomasV1 wrote:

please read bug 12130's description more carefully.
the javascript creates an edit form ; this is why the line break is eaten.

Makes sense.

But do this mean that the code of the <noinclude></noinclude> in the beginning of the page and of the other in the and of the page are not added by the script to the edit form before saving? How is the code added to the page when saving it currently?

Wouldn't that solve the problem (at least in the context of proofreadng pages on Wikisources) since then when saving the page the line breaks would not be in the beginning of the edit form?

thomasV1 wrote:

no, noinclude sections are added server-side, after the page is posted.

(it was done client-side at some point, but this approach was not robust)

I understood.

Thanks for clarifying.

• This bug has been marked as a duplicate of bug 12130 ***

I'm not so sure this is bug 12130 -- that was caused by the edit form that is output from MediaWiki not containing an extra newline in the <textarea> source.

If you're creating a new textarea, or changing the contents of the existing textarea, in your JS, then the bug 12130 fix won't affect this at all I think.

Please provide some links to where this problem can be reproduced.

Ok found this link http://en.wikisource.org/wiki/Page:A_Treatise_on_Geology,_volume_1.djvu/10 and details in the older discussion at http://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium&oldid=2201305#Why_line_breaks_are_removed.3F

While this greatly resembles bug 12130, it's not exactly the same. The <textarea> in the actual HTML doesn't start with any blank lines; it begins with a <noinclude> section and whatnot.

Another edit form isn't loaded via XHR or anything, so it looks like the ProofreadPage JS is responsible for modifying the textarea contents.

So either ProofreadPage is altering it in a similar way (creating a new <textarea> from HTML source?) or it's stripping the newline itself when it extracts the new value.

Ok, I can confirm locally that having the bug 12130 fix in doesn't help the ProofreadPage case.

Culprit found in proofread.js; a bunch of HTML structure is generated in manual string concatenation, including the textareas:

container.innerHTML = '' +

		'<div id="prp_header" style="">' +
		'<span style="color:gray;font-size:80%;line-height:100%;">' +
		escapeQuotesHTML( mediaWiki.msg( 'proofreadpage_header' ) ) + '</span>' +
		'<textarea name="wpHeaderTextbox" rows="2" cols="80" tabindex=1>' + escapeQuotesHTML( pageHeader ) + '</textarea><br />' +
		'<span style="color:gray;font-size:80%;line-height:100%;">' +
		escapeQuotesHTML( mediaWiki.msg( 'proofreadpage_body' ) ) + '</span></div>' +
		'<textarea name="wpTextbox1" id="wpTextbox1" tabindex=1 style="height:' + ( self.DisplayHeight - 6 ) + 'px;">' +
			escapeQuotesHTML( pageBody ) + '</textarea>' +
		'<div id="prp_footer" style="">' +
		'<span style="color:gray;font-size:80%;line-height:100%;">' +
		escapeQuotesHTML( mediaWiki.msg( 'proofreadpage_footer' ) ) + '</span><br />' +
		'<textarea name="wpFooterTextbox" rows="2" cols="80" tabindex=1>' +
		escapeQuotesHTML( pageFooter ) + '</textarea></div>';

Adding \ns after the opening <textarea> tags resolves it.

Fixed on trunk in r98583.

Merged to REL1_18 in r98584; still needs merging to 1.18wmf1 for deployment to wikis that have been upgraded to 1.18. 1.17 wikis will be upgraded soon enough. :)

Created attachment 9173
remove an extra LF added as a workaround against a bug already fixed

Reopening as this patch is fine but not sufficient. As you can see http://fr.wikisource.org/w/index.php?title=Page:Griolet_-_Du_m%C3%A9canisme_de_la_cicatrisation_dans_les_parties_molles.djvu/53&diff=2817741&oldid=2817518 each null edit now add an extra lf in the third edit form because there was a workaround to avoid the removal of the LF when rebuilding the text in ProofreadPage_body.php (but only to the third edit form) by adding an extra LF, patch attached to remove this extra LF.

Attached:

Someone has made a change at
http://svn.wikimedia.org/viewvc/mediawiki/branches/wmf/1.18wmf1/extensions/ProofreadPage/ProofreadPage_body.php?r1=97502&r2=99979&pathrev=100002

and this has broken the scripting in that the hard return (LF) has been placed BEFORE the <noinclude> tag and now adds a pagination line to all terminations and now breaks things on every edited page. :-(

I do not believe that Phe's suggested change at https://bugzilla.wikimedia.org/attachment.cgi?id=9173&action=diff has been successfully implemented.

I am told that the commit is at http://svn.wikimedia.org/viewvc/mediawiki?view=revision&amp;revision=99164

Examples of the breaks are

(edited page)
https://en.wikisource.org/w/index.php?title=Page:Seventeen_lectures_on_the_study_of_medieval_and_modern_history_and_kindred_subjects.djvu/300&diff=prev&oldid=3486234

(look at the new gap b/w pp.288-289 which should be continuous)
https://en.wikisource.org/wiki/Page%3ASeventeen_lectures_on_the_study_of_medieval_and_modern_history_and_kindred_subjects.djvu/301

Please fix it as soon as you can! It's a plague! All from active users of it.wikisource hope that the bug will disappear in hours. :-(

I've tagged the fix for 1.18wmf1, will go out later today.

(In reply to comment #18)

I've tagged the fix for 1.18wmf1, will go out later today.

Deployed a while ago.

(In reply to comment #19)

(In reply to comment #18)

I've tagged the fix for 1.18wmf1, will go out later today.

Deployed a while ago.

Is the correction already live? I still see the bug on it.wikisource

(In reply to comment #20)

(In reply to comment #19)

(In reply to comment #18)

I've tagged the fix for 1.18wmf1, will go out later today.

Deployed a while ago.

Is the correction already live? I still see the bug on it.wikisource

It's live, yes. Note that the fix in r99164 doesn't remove the line break, it just moves it to before instead of after the <noinclude> tag. Is that what you're seeing?

that is not the fix! that is the bug itself! :-) see comment 15 where Andrew Billinghurst writes about Phe's suggested change. In short words, we need that line break to be *removed*!

(In reply to comment #22)

that is not the fix! that is the bug itself! :-) see comment 15 where Andrew
Billinghurst writes about Phe's suggested change. In short words, we need that
line break to be *removed*!

Did so in r101183, and deployed. Is it fixed now?

The line break was removed in the initial fix implemented by Brion, the issue that this introduced a different problem. It was reopened on this bug (maybe incorrectly by me). I see that both issues are resolved (well they are at English Wikisource) and boldly calling it resolved. If it isn't resolved at all WS wikis then we need to identify which.

(In reply to comment #23)

(In reply to comment #22)

that is not the fix! that is the bug itself! :-) see comment 15 where Andrew
Billinghurst writes about Phe's suggested change. In short words, we need that
line break to be *removed*!

Did so in r101183, and deployed. Is it fixed now?

The main problem seems to be fixed but another one has appeared:

If no line break is inserted after the <noinclude> tag the last line will appear as a own paragraph in the "page"-namespace.
http://sv.wikisource.org/w/index.php?title=Sida%3ANils_Holgerssons_underbara_resa_genom_Sverige%2C_band_1.djvu%2F95&action=historysubmit&diff=147571&oldid=147564

Although this can be mended manually and doesn't effect the transcluded part, it will become very tedious in the long run.

(In reply to comment #25)

(In reply to comment #23)

(In reply to comment #22)

that is not the fix! that is the bug itself! :-) see comment 15 where Andrew
Billinghurst writes about Phe's suggested change. In short words, we need that
line break to be *removed*!

Did so in r101183, and deployed. Is it fixed now?

The main problem seems to be fixed but another one has appeared:

If no line break is inserted after the <noinclude> tag the last line will
appear as a own paragraph in the "page"-namespace.
http://sv.wikisource.org/w/index.php?title=Sida%3ANils_Holgerssons_underbara_resa_genom_Sverige%2C_band_1.djvu%2F95&action=historysubmit&diff=147571&oldid=147564

Although this can be mended manually and doesn't effect the transcluded part,
it will become very tedious in the long run.

I propose this fix: add a newline after <noinclude> on saving, but only if $editpage->footer does not start with a newline. This way we're not adding a new newline on every save (that was the original problem), and in the same time we make sure that the footer is always separated from the body by a newline.

BTW, thank you very much for fixing the main problem!

The main problem seems to be fixed but another one has appeared:

If no line break is inserted after the <noinclude> tag the last line will
appear as a own paragraph in the "page"-namespace.
http://sv.wikisource.org/w/index.php?title=Sida%3ANils_Holgerssons_underbara_resa_genom_Sverige%2C_band_1.djvu%2F95&action=historysubmit&diff=147571&oldid=147564

Although this can be mended manually and doesn't effect the transcluded part,
it will become very tedious in the long run.

I propose this fix: add a newline after <noinclude> on saving, but only if
$editpage->footer does not start with a newline. This way we're not adding a
new newline on every save (that was the original problem), and in the same time
we make sure that the footer is always separated from the body by a newline.

BTW, thank you very much for fixing the main problem!

Agreed, the trouble is we really need a linefeed either before the noinclude (which break transclusion) or after the noninclude tag (but if added unconditionally it breaks because this LF is added to existing one), without any linefeed, as actually, the sequence "last line - 1\nlast line<noinclude><references /></div></noinclude> generate a <p> between line1 and line2 see http://fr.wikisource.org/w/index.php?title=Page:Chaptal_-_Chimie_appliqu%C3%A9e_%C3%A0_l%E2%80%99agriculture,_Tome_1.djvu/139&oldid=2869917 and the sequence "\n\nlast line<noinclude><references /></div></noinclude> doesn't generate a <p> before the last line, see http://fr.wikisource.org/w/index.php?title=Page:Chaptal_-_Chimie_appliqu%C3%A9e_%C3%A0_l%E2%80%99agriculture,_Tome_1.djvu/139&oldid=2869942. So there is no way to get the wanted generated code in Page: namespace. Candalua solution should work.