Parser issue for HTML definition list
Closed, ResolvedPublic


Author: ycombarnous

MW seems to be handling unproperly the HTML definitions tags.

<DT>my definition header</DT>

Will result in some tags being rendered as html special chars and show up in article rendering.

Version: 1.11.x
Severity: enhancement


bzimport raised the priority of this task from to Low.
bzimport set Reference to bz11748.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Oct 23 2007, 5:57 PM

jlerner wrote:

I'm seeing this as well on 1.11.0 - but not on Wikipedia (1.13alpha (r34478)).

ayg wrote:

This has probably been fixed at some point since 1.11.0. If you can reproduce in 1.12, or preferably 1.13alpha, please reopen.

bugs wrote:

I don't know if this was working in 1.12 through 1.15, but i am definitely experiencing this problem in 1.16.

Steps to reproduce:

  1. Create new article, edit existing article, whatever.
  1. In body of article, create a simple definition list using the HTML syntax (not the colons and semicolons). Something like the following:

<dt>test 1</dt>
<dd>test test test test test</dd>
<dt>test 2</dt>
<dd>test test test test test</dd>

  1. Save article.

Expected results:

The code above should appear more or less verbatim in the final article source.

Actual results:

The final article source (as seen in View > Source) looks like this:


<dt>test 1&lt;/dt&gt;
<dd>test test test test test&lt;/dd&gt;
<dt>test 2&lt;/dt&gt;
<dd>test test test test test&lt;/dd&gt;

As you can see, it insists on converting the closing tags to plain text, which results in '</dt>' and so on appearing in the rendered article. White space doesn't seem to come into it (for example i can put everything on one line and the same issue occurs).

This problem also seems to affect the closing tags of other HTML elements *inside* more advanced DLs. For instance, i have a DL that contains <div><code>...</code></div>, and the closing tags for the code/div elements are rendered similarly to the above.

I have reproduced this on two different MediaWiki installations on DreamHost; one has a few extensions/modifications installed, but the other is pretty much vanilla (all extensions disabled, no core files modified, no fancy settings in place).

Product Version
MediaWiki 1.16.0
PHP 5.2.15 (cgi-fcgi)
MySQL 5.1.39-log

ayg wrote:

Cannot reproduce in 1.18alpha. Can anyone else test in 1.16.0 and see if they get the same problem? I suspect it's configuration-dependent.

Confirmed in 1.16.0, REL1_17 and trunk. Passes if you have $wgUseTidy = true. Added failing parser test in r79679.

ayg wrote:

Typical. I wish we could kill $wgUseTidy.

wicke wrote:

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

Merged in, will be in MediaWiki 1.21.