Page MenuHomePhabricator

Showing Table of contents sometimes requires reload (Vector 22, wmf.5)
Closed, ResolvedPublicBUG REPORT

Description

Bonjour,

We are currently using WMF 5 (0aac639) and Vector 2022, since the activation of Table of contents, we notice that this one is not necessarily displayed at the first viewing of the page, and that it is sometimes necessary to refresh it so that it appears.

Once this is available, an additional shift is observed on the right side of the page where the two margins (right-left) are not equal:

image.png (959×1 px, 675 KB)

image.png (961×1 px, 678 KB)

See also our production site (activated by default): Fallout-wiki.com

Thanking you for your work,

Sincerely,

Kims

Related Objects

Event Timeline

Aklapper renamed this task from Table of contents does not work properly (Vector 22, WMF 5) to Showing Table of contents sometimes requires reload (Vector 22, wmf.5).Mar 31 2022, 11:03 AM
Jdlrobson subscribed.

Thanks for the report! We're investigating this issue in T303860.

(Also the feature is still in development so I don't recommend using it right now in a production setting!)

ovasileva subscribed.

Moving to blocked on others, can check whether this is still occurring once T303860: ToC: ToC appears empty on certain pages is done

@ovasileva this is actually the issue I'm still investigating. I've closed the other one, as this describes the remaining issue perfectly.

Jdlrobson raised the priority of this task from Low to High.Apr 1 2022, 4:55 PM
Jdlrobson edited projects, added MediaWiki-Parser; removed Vector (legacy skin).
Jdlrobson added a subscriber: cscott.

This is an issue in the MediaWiki parser that I'm still trying to debug.

I'm replicating it like follows:

  1. Set:
$wgVectorTableOfContents = [
	'default' => false,
];
  1. Load page
  2. Set
$wgVectorTableOfContents = [
	'default' => true,
];
  1. Load same page

For the 2nd load, it looks like the Parser calls internalParse with $isMain set to true and finalizeHeadings twice when the content is cached. The second call to finalizeHeadings results in an empty array of sections being stored.

Digging deeper, this seems to be triggered by the line:

$this->msg( 'retrievedfrom' )
			->rawParams( '<a dir="ltr" href="' . $url . '">' . $url . '</a>' )
			->parse();

That leads to setSections being called with empty sections array.

It looks like the message parser shares the OutputPage instance of Skin, so this seemingly harmless call.

I'm trying to dig out a minimum test case, but the expectation in Skin is that the OutputPage should refer to the page being outputted and frozen, not something that a call to message parsing can be modified. @cscott any idea what might be going on here?

Change 776239 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Skin::msg function should not have side effects on OutputPage

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

ParserCache clearly has something to do with this. Perhaps setSections is not being called in this situation... I'm down a rabbit hole.

Change 776245 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] [Article] setSections must be called on non-cached parser output

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

Change 776239 abandoned by Jdlrobson:

[mediawiki/core@master] Skin::msg function should not have side effects on OutputPage

Reason:

I think I've got to the bottom of this.

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

Thanks for the report! We're investigating this issue in T303860.

(Also the feature is still in development so I don't recommend using it right now in a production setting!)

Hello,

Sorry I didn't see your answer, we have indeed disabled the feature, we had activated it to see if logs came up to help debugging :)

Sincerely,

Kims

Change 776245 merged by jenkins-bot:

[mediawiki/core@master] [Article] setSections must be called on non-cached parser output

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

Jdlrobson added subscribers: nray, bwang.

@nray since this is tricky to test on beta cluster, could you please verify the fix locally and sign this off?

This appears to be working as intended. I was able to replicate the issue locally on the parent commit of the patch that got merged but was not able to replicate it with the patch. Therefore, I am resolving 😀