This is a nasty edge case (bug) in section-template conflict resolution code caused by newlines at the top of templates (ex: https://pl.wikipedia.org/wiki/Wikipedia:Poczekalnia/biografie?action=edit&veswitched=1 will have 2 newlines after the noincludes are processed). This causes the template output to start with a <span> wrapping newlines followed by a heading / section. This causes template-section conflicts and since there are multiple of them at the top-level, the effects cascade.

Thanks for the simpler page. Will look later today.

In T265737#6550498, @matmarex wrote:

There is an about="#mwt2 about-group, which covers most of the page, but there is no initial element with about="#mwt2" typeof="mw:Transclusion" that would describe it.

Also fails on /w/rest.php/en.wikipedia.org/v3/page/pagebundle/Eline_De_Munck/916596722

@Dzahn I was supposed to verify that rt testing works from that new server but haven't done it yet. Lost track of this. I'll kick off the next test run from that server. After we shift over all testing there, you can reimage scandium.

i.e. unclosed / unbalanced tags is not specific to Cite extension.

I am not convinced we need to support them. Those feel like they can be folded into the Linting project.

The error is reproducible with this snippet from frwiki. Everything is required including the extra newlines.

<noinclude>
{{Documentation}}
<noinclude>

In T265320#6542609, @JTannerWMF wrote:

Looks like the Parsing team is looking into this

Filed T265411: Simple Wikilinks with templated targets is missing information in data-mw to distinguish it from Piped Wikilinks with templated targets

Ya, caching is a different issue. As Parsoid starts generating all the same metadata that core does, that issue will get resolved. In general, even in wikitext like this [[{{LOCALDAY}}. {{LOCALMONTHNAME}}]] there is nothing preventing me from editing source to say [[{{LOCALDAY}}. {{LOCALMONTHNAME}}| 11th Oktober blah blah]]. How would VE know what link text is okay to edit and what is not? One option is for Parsoid to generate special markup for some subset of parser functions to prevent any editing of pieces of it. That will require some research to figure out what might be appropriate, but in the generic template link case [[{{1x|Foobar}}]], it is perfectly okay to edit just the link text.

What is the problem? If you edit the link text (and save or review changes), you see [[{{LOCALDAY}}. {{LOCALMONTHNAME}}|11th Oktober blah blah]] which is just fine. It is valid wikitext and represents the edit as well.

The dirty diff part will be addressed by the parent task that will apply to all subtasks. But, outside the fact that it is a dirty diff, is the actual normalization a problem?

In T263928#6530727, @TheConen wrote:

I honestly don't understand why VisualEditor/Parsoid doesn't use an internal mechanism that is independent of permission settings now that Parsoid is directly integrated into MediaWiki.

Good thought. This may potentially be doable with linting, but could be tricky in cases where categories, magic words, and the like are not present on their own new lines.

AFAICT, looks like all concerns have been addressed and docs updated. Assuming there are no new concerns, I'll resolve this ticket later this week. Thanks everyone!

Check https://www.mediawiki.org/wiki/Manual:How_to_debug#Logging .. I looked at that page, and my guess is that maybe Parsoid timed out on that page.

An alternate way of thinking about this is that we layer Parsoid and that not all of the integrated mediawiki functionality is available in standalone mode and the integrated mode layer sits on top of the standalone layer. So, Parser* classes are only used in the boundary between those two layers.

In T264782#6522895, @cscott wrote:

I think our entry points should actually take PageBundles, and we should have factory methods to create PageBundles efficiently from DOM without serializing to string.

Good to know! I am surprised that trailing whitespace in list items is that common.

Parsoid/JS support ends with 1.31 LTS (which I believe is June 2021). So, we need something for 9 months.

In T263928#6519568, @D3nnis3n wrote:

Well, it's not completely working. On a long page with a lot of modules it fails to connect with an error 500, but on normal sized ones it seems to work fine.
...
//EDIT:
It actually seems like this is the only page i can get this error to happen. Would a link to the page help?

@Dzahn @MoritzMuehlenhoff something you can fix?

In T263928#6515558, @Ciencia_Al_Poder wrote:

[ ... ]

We'll take a look at this in the week but given that our team is swamped now, it will take a few days to investigate well and we may not have immediate solutions for you all in a day or two. Once we figured out where and when the out-of-the-box config is breaking, we'll update the documentation that provides solutions to handle them.

We'll take a look next week but in case it helps anyone in the interim, https://twitter.com/aixnr/status/1310192041503141889 might be worth checking out.