Page MenuHomePhabricator

Centering the output of an extension improperly nests tags
Closed, ResolvedPublic

Description

Author: wikimedia-2005

Description:
Hi. I just installed a MediaWiki on my laptop, after using it a bit over at hrwiki.org and deciding that I liked it. One of
the first things I tried was to create an extension to let me render graphs with GraphViz [1]. Now I can write this:

<dot>digraph G {

foo [URL="foo.html"]
foo -> bar

}</dot>

And my extension saves the rendered graph image to a cache file and returns this HTML:

<map id="graphviz" name="graphviz">
<area shape="rect" href="foo.html" title="foo" alt="" coords="8,8,80,56" />
</map>
<img src="cache/dotneato/graphviz.png" width="87" height="159" border="0" usemap="GraphViz" />

MediaWiki renders it in the page this way, which is fine:

<p><map id="graphviz" name="graphviz">
<area shape="rect" href="foo.html" title="foo" alt="" coords="8,8,80,56" />
</map>
<img src="cache/dotneato/graphviz.png" width="87" height="159" border="0" usemap="GraphViz" />
</p>

Supposing I want to center this then, I write this:

<center><dot>digraph G {

foo [URL="foo.html"]
foo -> bar

}</dot></center>

Only the output is now not what I expect, and my browser (Safari 1.2.4) doesn't render it because of the improperly-
nested tags:

<div class="center"><map id="graphviz" name="graphviz">
<p><area shape="rect" href="foo.html" title="foo" alt="" coords="8,8,80,56" />
</map>
</p>
<img src="cache/dotneato/graphviz.png" width="87" height="159" border="0" usemap="GraphViz" /></div>

See, I open the <map> tag, then for some reason MediaWiki has opened a <p> in the middle of my code, then I close
my </map>, then MediaWiki closes its </p>, still within my code. I can work around the problem by putting my
<center> and <dot> tags on separate lines:

<center>
<dot>digraph G {

foo [URL="foo.html"]
foo -> bar

}</dot></center>

Then MediaWiki renders it correctly:

<div class="center">
<p><map id="graphviz" name="graphviz">
<area shape="rect" href="foo.html" title="foo" alt="" coords="8,8,80,56" />
</map>
<img src="cache/dotneato/graphviz.png" width="87" height="159" border="0" usemap="GraphViz" />
</p>
</div>

But I'm not sure why this workaround should be necessary, so this feels like a bug in MediaWiki. In fact it feels very
peculiar that MediaWiki is inserting tags into the middle of the code my extension returned. It seems to me like any
code that my extension returns should be echoed to the page verbatim.

[1] http://www.graphviz.org/


Version: 1.8.x
Severity: normal

Details

Reference
bz1483
TitleReferenceAuthorSource BranchDest Branch
Update function-schemata sub-module to HEAD (97ea4cd)repos/abstract-wiki/wikifunctions/wikilambda-cli!33jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (97ea4cd)repos/abstract-wiki/wikifunctions/function-orchestrator!142jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (97ea4cd)repos/abstract-wiki/wikifunctions/function-evaluator!179jforrestersync-function-schematamain
definitions: Fold Z1229/zh-classical into Z1152/lzh, delete the formerrepos/abstract-wiki/wikifunctions/function-schemata!98wsungdev-98main
definitions: Fold Z1501/zh-min-nan into Z1221/nan, delete the formerrepos/abstract-wiki/wikifunctions/function-schemata!97wsungdev-97main
add fix for "Nonetype' has no len()' when a feed delivers no contentlegoktm/rawdog!2dzahnmainmain
Customize query in GitLab

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:12 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz1483.
bzimport added a subscriber: Unknown Object (MLST).

Still appears in current version, see testcase here: [[hu:User:Tgr/bug 1483]].

The center tag also breaks auto paragraph formatting (<p> tags are not inserted
where they should).

gubbubu wrote:

Yes, the center tag also breaks auto paragraph formatting (<p> tags are not
inserted where they should) using together with math tags.

Seems to be working fine now (though the extension output is wrapped in an extra <p> if it starts on a new line, but that's still correct syntax, and does not cause any visible difference with the standard stylesheets). Fixed by the new parser?

The strange <p> behavior is probably independent from this, see bug 9207.

Marking FIXED per comment #3. The <p> issue is separate and already logged at 9207.