using the editintro url argument forces a new line between minnor edit and watch this page box
Closed, ResolvedPublic

Description

If you add an &editintro=foo to the url of a page when editing, it causes a line
break between the minnor edit and watch this page checkmarks.
See
http://en.wikinews.org/w/index.php?action=edit&preload=Template%3ANew_page&editintro=Template%3ANew_article_intro&title=afdashjkldfiks&create=Create+article
for example. Happens for every editintro I've tried. tested on both the english
wikipedia and wikinews. the html is:

<input tabindex='2' type='text' value="" name='wpSummary' id='wpSummary'
maxlength='200' size='60' /><br />

<input name="wpMinoredit" type="checkbox" value="1" tabindex="3" accesskey="i"
id="wpMinoredit" />&nbsp;<label for='wpMinoredit' title="Mark this as a minor
edit [i]" accesskey="i"><p>This is a minor edit</p>

</label>
<input name="wpWatchthis" type="checkbox" value="1" checked="checked"
tabindex="4" accesskey="w" id="wpWatchthis" />&nbsp;<label for='wpWatchthis'
title="Add this page to your watchlist [w]" accesskey="w"><p>Watch this page</p>

</label>

on a page with an editintro vs

<input tabindex='2' type='text' value="" name='wpSummary' id='wpSummary'
maxlength='200' size='60' /><br />

<input name="wpMinoredit" type="checkbox" value="1" tabindex="3" accesskey="i"
id="wpMinoredit" />&nbsp;<label for='wpMinoredit' title="Mark this as a minor
edit [i]" accesskey="i">This is a minor edit</label>
<input name="wpWatchthis" type="checkbox" value="1" checked="checked"
tabindex="4" accesskey="w" id="wpWatchthis" />&nbsp;<label for='wpWatchthis'
title="Add this page to your watchlist [w]" accesskey="w">Watch this page</label>

Note: I saw this at
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Editintro_bug.3F
and put it here as I thought this is probably the right place.


Version: 1.10.x
Severity: normal
OS: Linux
Platform: PC
URL: http://en.wikipedia.org/w/index.php?action=edit&preload=User%3ASimetrical/Sandbox&editintro=User%3ASimetrical/Sandbox&title=afdashjkldfiks&create=Create+article

bzimport added a project: MediaWiki-Page-editing.Via ConduitNov 21 2014, 9:36 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz9252.
Bawolff created this task.Via LegacyMar 11 2007, 8:45 AM
bzimport added a comment.Via ConduitJun 22 2007, 7:48 AM

herd wrote:

Workaround hack, *not* a fix.

Add to MediaWiki:Common.css:

.editOptions p {display:inline;}

bzimport added a comment.Via ConduitJun 22 2007, 2:18 PM

robchur wrote:

Not present in current trunk as far as I can see, at least; there are no line breaks emitted in HTML which would cause a change in page appearance. The source does differ a touch, but that has no effect on the final page.

bzimport added a comment.Via ConduitJun 22 2007, 3:12 PM

ayg wrote:

The difference is that "This is a minor edit" and "Watch this page" are enclosed in <p> in the editintro case. I can reproduce this; changing URL to Wikipedia, where more people have accounts and so can see the issue. It looks like the labels are for some reason getting parsed non-inline.

Bawolff added a comment.Via ConduitJun 22 2007, 10:12 PM

Well, the css fixes my problem. Thanks.

bzimport added a comment.Via ConduitJun 23 2007, 5:02 AM

herd wrote:

(In reply to comment #2)

Not present in current trunk as far as I can see, at least

Note that ".editOptions p {display:inline;}" is currently in http://test.wikipedia.org/wiki/MediaWiki:Common.css so test.wikipedia will not show the problem (comment it out to see).

Seems likely to be caused by HTMLTidy?

brion added a comment.Via ConduitJun 25 2007, 4:55 PM

I think some parser state is not getting reset properly...

Can only reproduce the problem locally when $wgUseTidy is enabled.

The check box texts are produced with wfMsgExt() with the 'parseinline' option, so the <p>s _should_ be stripped. But something ain't quite right...

If I change wfMsgExt() to be willing to strip one more newline from the end of the parsed HTML, then we get the expected output.

Alternatively, if I change EditPage::showCustomIntro() to output via:

$wgOut->addHtml( $wgOut->parse( $revision->getText() ) );

instead of:

$wgOut->addSecondaryWikiText( $revision->getText() );

then it also works -- that is, the extra newlines don't get slipped in. So it's definitely something inconsistent in the parser state... ugh!

bzimport added a comment.Via ConduitAug 9 2007, 11:23 AM

webboy wrote:

Patch to fix this bug

This bug is caused by two things:

OutputPage::addWikiTextTitle() (used by OutputPage::addSecondaryWikiText()) sets

$popts = $this->parserOptions();
$popts->setTidy($tidy); ($tidy = true)

but doesn't reset the Tidy setting. Therefor Tidy is used when parsing [[MediaWiki:minoredit]], [[MediaWiki:watchthis]] and [[MediaWiki:cancel]]

wfMsgExt( *, 'parseinline' ) doesn't work in combination with Tidy because of trailing newlines.

This patch fixes both issues.

Attached: bug9252.patch

Raymond added a comment.Via ConduitAug 23 2007, 12:14 PM
  • Bug 11038 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitOct 9 2007, 7:10 PM

webboy wrote:

Fixed in r25793

Add Comment