Last modified: 2014-06-12 05:32:49 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 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