doBlockLevels inserts pre-tags in a text created by an extension
Closed, DeclinedPublic
Actions

Assigned To

None

Authored By

	• bzimport
	Jan 12 2005, 7:34 PM

Description

Author: chmarndt

Description:
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

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?

Version: 1.20.x
Severity: normal
See Also:
T68495: MathML elements are filtered out on betalabs

Details

Reference: bz1319

Title	Reference	Author	Source Branch	Dest Branch
add LICENSE and a notice in the README.md	repos/releng/gitlab-webhooks!11	brennen	review/brennen/license	main
local.json: update footer links for foundation wiki	repos/phabricator/deployment!4	brennen	footer-updates	wmf/stable
Use node16 for fresh	repos/releng/cli!379	addshore	fresh-node-16	main

Customize query in GitLab

Related Objects

Mentioned Here: T68495: MathML elements are filtered out on betalabs

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 21 2014, 8:08 PM

• bzimport added projects: MediaWiki-General, Parser.

• bzimport set Reference to bz1319.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Jan 12 2005, 7:34 PM

jeluf wrote:

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.

Parser::strip() is precisely the function that is used in the given example. It
is broken, because unstrip() is done before doBlockLevels().

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.

Bug 1772 has been marked as a duplicate of this bug. ***

Bug 8997 has been marked as a duplicate of this bug. ***

Bug 27906 has been marked as a duplicate of this bug. ***

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.

Danny_B edited projects, added MediaWiki-Parser, MediaWiki-extensions-Other; removed Parser, MediaWiki-General.Jul 8 2016, 10:16 PM

Pppery merged a task: T10997: Parser hook output block level corruption.Jan 21 2017, 5:05 PM

Pppery added a subscriber: • demon.

Pppery merged a task: T29906: Parser inserts <pre> on lines begining with space in raw html output from parser->setHook type hook..Jan 22 2017, 4:54 PM

Pppery added a subscriber: Nischayn22.

• demon unsubscribed.Mar 9 2017, 9:45 PM

Liuxinyu970226 updated the task description. (Show Details)Sep 21 2017, 12:16 PM

Liuxinyu970226 edited subscribers, added: Aklapper; removed: • wikibugs-l-list.

Liuxinyu970226 subscribed.