Last modified: 2012-01-14 22:55:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28028, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26028 - Script should not remove line-breaks after initial noinclude tags
Script should not remove line-breaks after initial noinclude tags
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ProofreadPage (Other open bugs)
unspecified
All All
: Normal normal with 6 votes (vote)
: ---
Assigned To: ThomasV
http://en.wikisource.org/w/index.php?...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-20 19:43 UTC by Helder
Modified: 2012-01-14 22:55 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
remove an extra LF added as a workaround against a bug already fixed (627 bytes, patch)
2011-10-06 14:22 UTC, Philippe Elie
Details

Description Helder 2010-11-20 19:43:03 UTC
As explained at Wikisource, there is some script removing line-breaks when they are inserted after the closing </noinclude> of the initial section of the page. This was noted when editing pages in "Page:" namespace on Wikisources.

The problem only happens when javascript is enabled in browser.

When an editor is correcting a typo in such a page where there are line-breaks after the initial noinclude section, its edit will also remove the line-break even if if when previewing the changes made there was no lines removed. This is annoying, since the user is not aware that he will be removing that and can only detect that after saving the page. Then, to correct the problem it will needed to disable javascript, or add more lines than the MediWiki will save in the wikicode of the page (and he still need to hope no one else edit the page afterwards).
Comment 1 Derk-Jan Hartman 2010-11-21 01:01:54 UTC
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.)
Comment 2 ThomasV 2010-11-21 13:34:31 UTC
I guess this a duplicate of bug 12130

*** This bug has been marked as a duplicate of bug 12130 ***
Comment 3 Helder 2010-11-21 14:20:50 UTC
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
Comment 4 ThomasV 2010-11-21 16:07:08 UTC
please read bug 12130's description more carefully.
the javascript creates an edit form ; this is why the line break is eaten.
Comment 5 Helder 2010-11-21 16:30:01 UTC
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?
Comment 6 ThomasV 2010-11-21 16:43:19 UTC
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)
Comment 7 Helder 2010-11-21 16:47:30 UTC
I understood.

Thanks for clarifying.

*** This bug has been marked as a duplicate of bug 12130 ***
Comment 8 Brion Vibber 2011-09-30 22:58:46 UTC
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.
Comment 9 Brion Vibber 2011-09-30 23:03:43 UTC
Please provide some links to where this problem can be reproduced.
Comment 10 Brion Vibber 2011-09-30 23:12:45 UTC
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.
Comment 11 Brion Vibber 2011-09-30 23:25:14 UTC
Ok, I can confirm locally that having the bug 12130 fix in doesn't help the ProofreadPage case.
Comment 12 Brion Vibber 2011-09-30 23:34:46 UTC
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.
Comment 13 Brion Vibber 2011-09-30 23:40:10 UTC
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. :)
Comment 14 Philippe Elie 2011-10-06 14:22:35 UTC
Created attachment 9173 [details]
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.
Comment 15 billinghurst 2011-10-17 11:44:12 UTC
Someone has made a change at 
r1=97502&r2=99979&pathrev=100002">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.
Comment 17 Alessandro Brollo 2011-10-27 23:25:44 UTC
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. :-(
Comment 18 Roan Kattouw 2011-10-28 08:51:28 UTC
I've tagged the fix for 1.18wmf1, will go out later today.
Comment 19 Roan Kattouw 2011-10-28 13:55:32 UTC
(In reply to comment #18)
> I've tagged the fix for 1.18wmf1, will go out later today.
Deployed a while ago.
Comment 20 Candalua 2011-10-28 17:26:52 UTC
(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
Comment 21 Roan Kattouw 2011-10-28 17:29:41 UTC
(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?
Comment 22 Candalua 2011-10-28 17:39:11 UTC
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*!
Comment 23 Roan Kattouw 2011-10-28 19:57:11 UTC
(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?
Comment 24 billinghurst 2011-10-28 21:19:13 UTC
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.
Comment 25 Thurs 2011-10-28 21:24:30 UTC
(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.
Comment 26 Candalua 2011-10-28 23:11:29 UTC
(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!
Comment 27 Philippe Elie 2011-10-29 15:12:50 UTC
> > 
> > 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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links