Last modified: 2007-10-09 19:10:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9252 - using the editintro url argument forces a new line between minnor edit and watch this page box
using the editintro url argument forces a new line between minnor edit and wa...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.10.x
PC Linux
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?a...
: patch, patch-need-review
: 11038 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-11 08:45 UTC by Bawolff (Brian Wolff)
Modified: 2007-10-09 19:10 UTC (History)
5 users (show)

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


Attachments
Patch to fix this bug (1.06 KB, patch)
2007-08-09 11:23 UTC, Jelte (WebBoy)
Details

Description Bawolff (Brian Wolff) 2007-03-11 08:45:19 UTC
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.
Comment 1 Splarka 2007-06-22 07:48:10 UTC
Workaround hack, *not* a fix. 

Add to MediaWiki:Common.css:

 .editOptions p {display:inline;}
Comment 2 Rob Church 2007-06-22 14:18:49 UTC
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.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-22 15:12:10 UTC
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.
Comment 4 Bawolff (Brian Wolff) 2007-06-22 22:12:27 UTC
Well, the css fixes my problem. Thanks.
Comment 5 Splarka 2007-06-23 05:02:15 UTC
(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?
Comment 6 Brion Vibber 2007-06-25 16:55:39 UTC
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!
Comment 7 Jelte (WebBoy) 2007-08-09 11:23:22 UTC
Created attachment 3979 [details]
Patch to fix this bug

This bug is caused by two things:

1)
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]]

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

This patch fixes both issues.
Comment 8 Raimond Spekking 2007-08-23 12:14:35 UTC
*** Bug 11038 has been marked as a duplicate of this bug. ***
Comment 9 Jelte (WebBoy) 2007-10-09 19:10:11 UTC
Fixed in r25793

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


Navigation
Links