Created attachment 10402
The bug NOT happening on 1.20alpha (localhost)

Attached:

[1] r113190, bug 19416)
[2] r113198 MFT 1.19wmf1 r113190
[3] r113200 revert MFT 1.19wmf1 r113190

Rephrasing summary, not limited to list item inline context.

Confirmed that the bug doesn't happen on master locally by Roan as well. But installing Tidy made the bug appear, so I suppose that's the "wmf config specific thing" thats causing it.

content hidden as private in Bugzilla

So it turns out that...

.. although Geshi IS using <pre> internally, the reason the skin's style didn't
apply (and hence bug 19416 filed) is because it has a very strong reset. Not a
problem so we can simply wrap another <pre> around that that is loose
from Geshi (geshi's output is simply encapsulated inside of our <pre>).

... Geshi is also using a few <div>s and <span>s internally as wrappings
sometimes (not always), but those are out of the MediaWiki extension's control.

.. and Tidy does not allow a <div> to be inside a <pre> so it closes the <pre>
before the, only child, <div> starts with a </pre>, and lets the div continue
outside the <pre> and them snips out the original </pre> at the and as a
closing tag with no matching opening tag.

A report from 2006 (still status: open) upstream shows a similar problem: http://sourceforge.net/tracker/?func=detail&atid=390963&aid=1604555&group_id=27659

Another similar problem about <div> inside <button>, although that one was recognized and fixed:

http://sourceforge.net/tracker/?func=detail&atid=390963&aid=1003361&group_id=27659

Console output:

krinkle$ tidy
<button><div>..</div></button>

krinkle$ tidy
<pre><div>..</div></pre>
line 4 column 1 - Warning: missing </pre> before <div>
line 4 column 18 - Warning: inserting implicit <pre>

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

Apparently W3 agrees that no <div> is allowed inside <pre>. imho stupid since both are block-level elements (or at least behave like one), but I suppose the easiest solution is to just not use enclose=div (which is the default for whatever reason), but that is fortunately still in the little part of the container that the extension does have control over.

Are there are reasons to support enclose=div ?

https://www.mediawiki.org/wiki/Special:Code/MediaWiki/113190

Needs reverting out of master till fixed, and MFT to 1.20wmf1

If we can't find a fix, then sure, revert it and reopen bug 19416.

But like I said in comment 9 there is a simple solution, I just wanted to make sure there are no gotchas before I commit it.

Okay so to remove the support for <source enclose=div> (which could previously be set manually from wikitext), these lines would have to change in SyntaxHighlight_GeSHi.class.php:

before:

		// Override default enclose from "enclose" attribute?
		$enclose = $pre;
		if ( isset( $args['enclose'] ) ) {
			if ( $args['enclose'] === 'div' ) {
				$enclose = GESHI_HEADER_DIV;
			} elseif ( $args['enclose'] === 'none' ) {
				$enclose = GESHI_HEADER_NONE;
			}
		}

after:

		// Override default enclose from "enclose" attribute?
		$enclose = $pre;
		if ( isset( $args['enclose'] ) ) {
			if ( $args['enclose'] === 'none' ) {
				$enclose = GESHI_HEADER_NONE;
			}
		}

and that would fix it mostly, however there is still the case where line-numering are enabling and then geshi will force a <div> still because of XHTML restrictions (no table allowed in <pre>), which makes perfect sense. So it looks like we'll have to fix this from mediawiki instead and provide a class we can use to give pre-styling.

Fixed by:

• https://gerrit.wikimedia.org/r/#q,Iaa2227348ca632d4a261c149bdf2428b4b48adc7,n,z
• https://gerrit.wikimedia.org/r/#q,I4ff5d0197ba8dc0dad3cafd03f2b120bc22e75cb,n,z

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

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

I suggest to purge all pages to re-render incorrectly rendered pages.