Last modified: 2010-05-15 15:59:39 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 12077 - TOC causes w3c html validation to fail (if Tidy not enabled)
TOC causes w3c html validation to fail (if Tidy not enabled)
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.11.x
All All
: Normal trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 13623 (view as bug list)
Depends on:
Blocks: html
  Show dependency treegraph
 
Reported: 2007-11-23 18:12 UTC by untrammelled
Modified: 2010-05-15 15:59 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Wiki markup for a page that shows html validation failure. (371 bytes, text/plain)
2007-11-23 18:12 UTC, untrammelled
Details

Description untrammelled 2007-11-23 18:12:19 UTC
Created attachment 4366 [details]
Wiki markup for a page that shows html validation failure.

The presence of a TOC in combination with headings in a particular sequence of levels causes w3c html validation to fail. This happens both on a live 1.11.0 wiki and on a freshly installed vanilla copy of mediawiki 1.11.0.

<example>

__TOC__

== First heading ==

=== subheading ===

== Second heading ==

</example>

This gives an HTML validation error.

If you remove the Second heading, the page validates OK.

If you remove the subheading instead, the page validates OK.

If you remove the __TOC__, or replace it with __NOTOC__ in articles with more headings, the page validates OK.

The attached file contains wiki markup of the above example ready for pasting into a new page.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-23 18:17:07 UTC
HTML output (indented here for better readability):

<table id="toc" class="toc" summary="Contents"><tr><td><div id="toctitle"><h2>Contents</h2></div>
<ul>
  <li class="toclevel-1">
    <a href="#First_heading"><span class="tocnumber">1</span> <span class="toctext">First heading</span></a>
    <ul>
      <li class="toclevel-2">
        <a href="#subheading"><span class="tocnumber">1.1</span> <span class="toctext">subheading</span></a>
      </li>
    </ul>
  </li>
  <li class="toclevel-1">
    <a href="#Second_heading"><span class="tocnumber">2</span> <span class="toctext">Second heading</span></a>
  </li>
</ul>
</li>
</ul>
</td></tr></table>

Note the stray </li></ul>.  Probably a stack maintained incorrectly or something.  Tidy fixes this on Wikimedia sites, of course.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-23 18:22:13 UTC
The fault lies somewhere in Parser::formatHeadings, which gives me a headache, so don't rely on me to fix it.  :)  If anyone wants to find the problem, or maybe rewrite that whole little mess, feel free to attach a patch and I'll look at it.
Comment 3 Jesse (Pathoschild) 2007-11-23 20:45:07 UTC
The validator reports no problems with my test (despite admittedly ugly HTML output). Could you link to a page that the validator fails?

* [[m:User:Pathoschild/Sandbox2]]
* http://validator.w3.org/check?uri=http%3A%2F%2Fmeta.wikimedia.org%2Fwiki%2FUser%3APathoschild%2FSandbox2
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-23 20:54:50 UTC
As I say, Tidy will fix it if enabled, as it is on Wikimedia wikis.  This is only an issue for third parties that do not use Tidy.
Comment 5 WTucker 2008-03-24 16:14:45 UTC
I have found the cause of this problem and have fixed it my own copy of 1.11.0.

The problem seems to be that the $prevtoclevel gets messed up right after an unindent.  The solution was to add a line to set it properly after unindenting.

Add a line after the first call to tocUnindent in Parser.php.  The new line should look like: $prevtoclevel = $toclevel;

So, before the change, the code looks like:

3597 if( $toclevel<$wgMaxTocLevel ) {
3598	if($prevtoclevel < $wgMaxTocLevel) {
3599		# Unindent only if the previous toc level was shown :p
3600		$toc .= $sk->tocUnindent( $prevtoclevel - $toclevel );
3601	} else {
3602		$toc .= $sk->tocLineEnd();
3603	}
3604 }

After the change, it looks like:

3597 if( $toclevel<$wgMaxTocLevel ) {
3598	if($prevtoclevel < $wgMaxTocLevel) {
3599		# Unindent only if the previous toc level was shown :p
3600		$toc .= $sk->tocUnindent( $prevtoclevel - $toclevel );
3601		$prevtoclevel = $toclevel;
3602	} else {
3603		$toc .= $sk->tocLineEnd();
3604	}
3605 }
Comment 6 Brion Vibber 2008-03-24 23:33:43 UTC
Applied in r32387 with a parser test case. Seems good. :)
Comment 7 Brion Vibber 2008-04-07 22:20:13 UTC
*** Bug 13623 has been marked as a duplicate of this bug. ***
Comment 8 Brion Vibber 2008-04-08 23:48:48 UTC
Went ahead and stuck this on 1.12 branch, r32998 for 1.12.1.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links