Linter detection of missing table end has a slight problem with noinclude tags
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	Jonesey95
	Oct 6 2023, 4:33 AM

Description

Steps to replicate the issue (include links if applicable):

Go to https://en.wikipedia.org/w/index.php?title=Template:Chamber_officers_box_begin&oldid=458494832

What happens?:

Notice that there is a Linter missing table end tag error detected.

What should have happened instead?:

No Linter missing table end tag error should have been detected.

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Adding whitespace like this: https://en.wikipedia.org/w/index.php?title=Template:Chamber_officers_box_begin&diff=prev&oldid=1178830428 made the error go away, but it should not be necessary.

This detection of missing table end tags was added in T295197.

Details

	Subject	Repo	Branch	Lines +/-
	[WIP] Pop noinclude tags from the end of table (row) attributes	mediawiki/services/parsoid	master	+24 -0

Customize query in gerrit

Related Objects

Mentioned In: T369317: False positive Linter "fostered content" errors apparently caused by noinclude tags
T369354: Linter seemingly ignored no-included content.
Mentioned Here: T373776: Parsoid does not correctly render <noinclude> if used with templates
T87069: Tokenizer buries comments inside tag attributes
T295197: Linter fails to detect missing table end

Event Timeline

Jonesey95 created this task.Oct 6 2023, 4:33 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 6 2023, 4:33 AM

This is affecting dozens, possibly hundreds, of template pages. If it could be fixed soon, that would be helpful.

https://en.wikipedia.org/wiki/Special:LintErrors/missing-end-tag?namespace=10

Here is a similar case that was causing a Linter false positive error:

https://en.wikipedia.org/w/index.php?title=Template%3AFb_oi_header&diff=1179382264&oldid=819685724

Change 964984 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] [WIP] Pop noinclude tags from the end of table (row) attributes

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

gerritbot added a project: Patch-For-Review.Oct 10 2023, 9:37 PM

The issue is that these noinclude tags are in the table (row) attribute position (as you've discovered in the workarounds) and Parsoid tokenizes noincludes as balanced units, so the entire noinclude tag and its contents, including the table end tag, gets hoisted into the attributes (and anything else on the closing noinclude tag's line)

This is affecting dozens, possibly hundreds, of template pages. If it could be fixed soon, that would be helpful.

It's unfortunately not so straightforward. The patch in T348296#9240867 does fix it using an approach similar to what was done in T87069 but needs refinement if it's even the right way to go.

Should the patch that was deployed in T295197 be reverted for the time being until this task can be addressed?

Please don't revert the changes, which have been helpful overall. I have been adding line breaks before the noinclude tags to a few hundred template pages, and that seems to resolve this false positive error without changing the table's display.

My understanding of noinclude tags has always been that they were essentially invisible to the parser, since that is how they seem to behave when the page is rendered. So as long as there is a new line after the noinclude tag, the table renders fine, but it sounds like the Parsoid page analyzer works differently from the actual renderer. It's too technical for me, but it you can find a way to make the Linting match the rendering (and the logical structuring of the wikitext), that would be great.

Arlolra moved this task from Backlog to Parsoid on the MediaWiki-extensions-Linter board.Oct 10 2023, 10:32 PM

Please don't revert the changes, which have been helpful overall.

My understanding of noinclude tags has always been that they were essentially invisible to the parser

Your understanding is correct; Parsoid is breaking that contract and needs to be fixed.

MSantos moved this task from Needs Triage to Bugs & Crashers on the Parsoid board.Oct 12 2023, 2:39 PM

MSantos added a project: Parsoid-Read-Views.

MSantos removed a project: Parsoid-Read-Views.Dec 7 2023, 3:28 PM

ihurbain removed a project: Content-Transform-Team-WIP.Apr 18 2024, 2:25 PM

Arlolra reassigned this task from Arlolra to ABreault-WMF.Jun 6 2024, 2:59 PM

ABreault-WMF mentioned this in T369354: Linter seemingly ignored no-included content..Jul 5 2024, 3:32 PM

ABreault-WMF mentioned this in T369317: False positive Linter "fostered content" errors apparently caused by noinclude tags.Jul 5 2024, 7:07 PM

ABreault-WMF merged a task: T369354: Linter seemingly ignored no-included content..Jul 5 2024, 7:18 PM

ABreault-WMF added subscribers: ShakespeareFan00, ABreault-WMF.

This should now be fixed by T373776

> git checkout v0.21.0-a6
> php bin/parse.php --pageName Template:Chamber officers box begin --revid 458494832 --wt2lint < /dev/null
{"type":"missing-end-tag","dsr":[0,216,38,0],"templateInfo":null,"params":{"name":"table","inTable":true}}

> git checkout v0.21.0-a7
> php bin/parse.php --pageName Template:Chamber officers box begin --revid 458494832 --wt2lint < /dev/null
{"type":"night-mode-unaware-background-color","dsr":[186,203,null,null],"templateInfo":{"name":"Template:Documentation"},"params":[]}
{"type":"night-mode-unaware-background-color","dsr":[186,203,null,null],"templateInfo":{"name":"Template:Documentation"},"params":[]}
{"type":"night-mode-unaware-background-color","dsr":[186,203,null,null],"templateInfo":{"name":"Template:Documentation"},"params":[]}
{"type":"night-mode-unaware-background-color","dsr":[186,203,null,null],"templateInfo":{"name":"Template:Documentation"},"params":[]}
{"type":"night-mode-unaware-background-color","dsr":[186,203,null,null],"templateInfo":{"name":"Template:Documentation"},"params":[]}

Change #964984 abandoned by Arlolra:

[mediawiki/services/parsoid@master] [WIP] Pop noinclude tags from the end of table (row) attributes

Reason:

In favour of Ied9ed72be7bbff6d7f323109bc0043f1aa0f4b70