Last modified: 2011-04-14 15:11:22 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 T23120, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 21120 - comment disrupts EditPage's formatting
comment disrupts EditPage's formatting
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.16.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-13 01:26 UTC by Lee Worden
Modified: 2011-04-14 15:11 UTC (History)
3 users (show)

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


Attachments

Description Lee Worden 2009-10-13 01:26:56 UTC
the attached micro-extension puts an HTML comment into the page's wikitext.  Originally this comment was a way of passing information to a later phase of the extension's processing.  However, when previewing a page, this causes extra line breaks to appear between the form fields at the bottom of the edit form.  I'm mystified.  I guess I'm not supposed to introduce HTML comments in the wikitext during parsing?

This "EditDisruptor" extension works on MW 1.13 as well as the current svn trunk.
Comment 1 Lee Worden 2009-10-13 01:27:50 UTC
Could not attach the php file.

Here it is:
<?php

$wgHooks['ParserAfterTidy'][] = 'edit_disruptor';

function edit_disruptor( &$parser, &$text )
{ $text .= "\n<!-- comment -->\n";
  return true;
}

?>
Comment 2 Brion Vibber 2009-10-14 17:41:13 UTC
Wikitext parsing is used in a lot of places in the UI, not just for displaying article pages, and those line breaks are indeed likely to muck things up.

You might be wanting another hook (something for display? or something specific to articles, or at least just checking what title you're processing?)
Comment 3 Lee Worden 2009-10-14 18:02:00 UTC
To clarify: that code there is a minimal example to reproduce the bug.  The actual extension that has the problem attaches a more meaningful comment to the page text (in its ParserAfterTidy hook) only at the appropriate times.  The purpose is to inject information into the parser cache, so it can be used to customize the sidebar depending on what's in the page, without requiring the page to be parsed on every view.  Using this HTML comment to pass armored information through the parser apparently does nothing bad to the parser, the parsed wikitext looks fine, but then it somehow causes wfMsgExt() to fail to strip the p tags from the labels attached to the form controls at the bottom of the edit form.  The form controls are strewn across multiple lines and look obviously wrong in the browser.  This is bizarre behavior, and can't possibly be desirable.  What's going on?
Comment 4 Lee Worden 2009-10-14 18:10:14 UTC
maybe you're right that it's doing that by disrupting parsing of the UI elements.  I'm going to give it a closer look. 
Comment 5 Lee Worden 2009-10-14 18:19:13 UTC
Yes, it's because sticking that comment on the end of the parsed messages interferes with the regexp it uses to remove p tags.  I need to work out how to get that material into the parser cache without messing up the other parser operations.
Comment 6 Lee Worden 2009-10-14 18:19:57 UTC
Thanks for giving me the hint I needed!
Comment 7 Alexandre Emsenhuber [IAlex] 2009-10-15 09:43:30 UTC
You can try to use ParserLimitReport hook (http://www.mediawiki.org/wiki/Manual:Hooks/ParserLimitReport) which is called when adding the "limit report" comment, or even better, use the page_props table to save this information (see ParserOutput::setProperty()).

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


Navigation
Links