Last modified: 2014-06-12 05:32:49 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 T3319, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1319 - doBlockLevels inserts pre-tags in a text created by an extension
doBlockLevels inserts pre-tags in a text created by an extension
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.20.x
All All
: Low normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser
: 1772 8997 27906 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-12 19:34 UTC by marndt
Modified: 2014-06-12 05:32 UTC (History)
6 users (show)

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


Attachments

Description marndt 2005-01-12 19:34:43 UTC
The extension I wrote creates a table and inserts  a 
<script> ... </script> section. However, it does not 
work as the call of the doBlockLevel-function destroys the 
structure, see 
 
<p><script type="text/javascript"> 
</p><p>	... 
</p><p>	</script> 
</p><p> 
 
Therefore, I placed the doBlockLevel-function directly after 
the internalParse-function. Having this done, the extension works.  
 
However, does this lead to any side effects?
Comment 1 JeLuF 2005-01-15 08:25:46 UTC
Our experience is that changing the order or parser steps always breaks something.
I'd recommend to escape the javascript by replacing it by a "cookie" that is
replaced by
the real java script at the end of the processing. See Parser::strip() for how
we do this.
Comment 2 Tim Starling 2007-01-02 23:27:48 UTC
Parser::strip() is precisely the function that is used in the given example. It
is broken, because unstrip() is done before doBlockLevels(). 
Comment 3 Tim Starling 2008-08-08 10:56:32 UTC
The reason Gabriel put doBlockLevels() last, after unstrip(), is because he wanted the output to be valid XHTML. That means not having block-level elements inside other block-level elements. doBlockLevels() will automatically detect nested block-level elements, and will break up the outer one to produce valid HTML. 

The solution I suggested, in private discussion years ago, is to have doBlockLevels() scan the stripped HTML for block-level elements, and if they are present, to treat the strip marker as a block-level element. Then the resulting string can be unstripped to produce valid XHTML. 
Comment 4 Tim Starling 2009-06-19 15:37:21 UTC
*** Bug 1772 has been marked as a duplicate of this bug. ***
Comment 5 Tim Starling 2009-06-19 15:37:40 UTC
*** Bug 8997 has been marked as a duplicate of this bug. ***
Comment 6 Bawolff (Brian Wolff) 2011-03-07 03:53:07 UTC
*** Bug 27906 has been marked as a duplicate of this bug. ***
Comment 7 Mark A. Hershberger 2011-04-12 15:33:43 UTC
The workaround for this problem is to replace newlines in the text that your extension is feeding to the parser with a space.  This is what extensions currently do.

This behavior is very unlikely to change since some extensions might rely on it.

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


Navigation
Links