⚓ T402456 More Parsoid TOC edge cases?

	Subject	Repo	Branch	Lines +/-
	Override TOCData object when not enough data to populate it	mediawiki/services/parsoid	master	+182 -51

Status	Subtype	Assigned	Task
Open	Release	None	T84936 Release VisualEditor-MediaWiki as "1.0"
Open		None	T50429 [Epic] Support editing parts of a page in VisualEditor-MediaWiki
Open		None	T54365 Explore performance gains from progressive (JIT?) de-alienation in VisualEditor
Open		None	T396539 Introduce a way to edit a span of text from within read mode
Open		None	T385558 Improve copy and paste from read mode to VE
Open		None	T174303 Copy-pasting linked ISBN numbers from view mode HTML into VisualEditor inserts wikitext links to Special:BookSources (it should turn them into magic links?)
Open	Feature	None	T54091 The read HTML should have hinting to allow full DOM copying (as opposed to just rich copying) from read mode into VE surfaces
Open		None	T55784 [EPIC] Use Parsoid HTML for all page views
Open		None	T272987 [EPIC] Parsoid read views for DiscussionTools
Resolved		cscott	T269630 Parsoid should support section editing links
Open		None	T297840 Populate ParserCache with Parsoid output as a post-edit hook
Open		None	T393717 Put lints in ParserOutput/RefreshLinksJob
Open	BUG REPORT	None	T393682 Wikifunctions fragments that trigger errors and try to put the page in a tracking category show it at the bottom of the view page, but the pages using the fragment do not appear on the category page
Open		None	T409815 SLI: MediaWiki system load
Open		None	T393716 [EPIC] RefreshLinksJob should use Parsoid-generated metadata
Open		None	T310511 Metadata comparison testing between Parsoid and the legacy parser
Open		None	T331483 Resolve differences between Parsoid & legacy parser TOC metadata output for template, extension, and parser-function generated content
Resolved		Jgiannelos	T402456 More Parsoid TOC edge cases?
Open		Jgiannelos	T415554 From TOC difftesting (legacy/parsoid): Differences in template handling from sections
Open		Jgiannelos	T415558 From TOC difftesting (legacy/parsoid): Mismatch when sections come from the same article
Open		Jgiannelos	T415563 From TOC difftesting (legacy/parsoid): Inconsistent index level between legacy and parsoid
Open		Jgiannelos	T415565 From TOC difftesting (legacy/parsoid): Section titles wrapped in html elements on parsoid

ssastry created this task.Aug 20 2025, 8:42 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 20 2025, 8:42 PM

ssastry added a parent task: T331483: Resolve differences between Parsoid & legacy parser TOC metadata output for template, extension, and parser-function generated content.Aug 20 2025, 8:42 PM

Jgiannelos edited projects, added Content-Transform-Team (Work In Progress); removed Content-Transform-Team.Aug 21 2025, 2:09 PM

ssastry moved this task from Backlog to Q3 FY25-26 on the Content-Transform-Team (Work In Progress) board.Aug 27 2025, 3:16 AM

From a quick look I think that for some reason parsoid doesn't enforce the threshold to decide whether TOC should be shown or not (only 2 heading shouldn't be shown).

The root cause is here:
https://gerrit.wikimedia.org/g/mediawiki/core/+/3bd70fd2a19de62673e2010900d452ee7dc7e958/includes/skins/components/SkinComponentTableOfContents.php#77

Regardless of the various flags (toc, notoc, forcetoc) that parsoid is setting as expected, the skin eventually asks for the TOCData.
Legacy returns no TOCData when TOC shouldn't be rendered where Parsoid returns TOCData always.

In the line above:

Legacy:

$tocData = null

Parsoid:

$tocData = <non empty instance of Wikimedia\Parsoid\Core\TOCData>

Jgiannelos claimed this task.Sep 23 2025, 3:54 PM

Jgiannelos moved this task from Q3 FY25-26 to In Progress on the Content-Transform-Team (Work In Progress) board.Sep 23 2025, 3:58 PM

More specifically when there are not enough matches for headlines, legacy parser returns early and doesn't set the TOCData here:
https://gerrit.wikimedia.org/g/mediawiki/core/+/3bd70fd2a19de62673e2010900d452ee7dc7e958/includes/parser/Parser.php#4307

Where parsoid always sets the tocdata here:
https://gerrit.wikimedia.org/g/mediawiki/core/+/3bd70fd2a19de62673e2010900d452ee7dc7e958/includes/Output/OutputPage.php#2437

That happens because when ParserOutput is initialized:

On legacy
- jsonData["TOCData"] is null
On parsoid
- jsonData["TOCData"] is populated

Change #1191423 had a related patch set uploaded (by Jgiannelos; author: Jgiannelos):

[mediawiki/services/parsoid@master] Force no-toc when not enough data to populate it

https://gerrit.wikimedia.org/r/1191423

gerritbot added a project: Patch-For-Review.Sep 25 2025, 2:06 PM

In T402456#11206527, @Jgiannelos wrote:
The root cause is here:
https://gerrit.wikimedia.org/g/mediawiki/core/+/3bd70fd2a19de62673e2010900d452ee7dc7e958/includes/skins/components/SkinComponentTableOfContents.php#77

Regardless of the various flags (toc, notoc, forcetoc) that parsoid is setting as expected, the skin eventually asks for the TOCData.
Legacy returns no TOCData when TOC shouldn't be rendered where Parsoid returns TOCData always.

In the line above:

Legacy:
$tocData = null
Parsoid:
$tocData = <non empty instance of Wikimedia\Parsoid\Core\TOCData>

Interesting -- is this all skins? or just a specific skin? Should we consider a skin bug? That apart, I am happy with just fixing parsoid to be compatible (hyrum's law ftw) as you've already done.

Its all skins (i think) assuming that skins wont put extra logic other what the skin component does.

Jgiannelos moved this task from In Progress to Code Review on the Content-Transform-Team (Work In Progress) board.Sep 29 2025, 1:52 PM

Jgiannelos moved this task from Code Review to To Deploy on the Content-Transform-Team (Work In Progress) board.Sep 29 2025, 3:10 PM

While debugging this with @cscott it turns out that one of the problems is that there is a typo in the wikitext of the page on the initial report: