Anton Sevarius at de.wiki reports that all the references in this article https://de.wikipedia.org/w/index.php?title=There_Will_Be_Blood&type=revision&diff=159587203&oldid=157742126 get nowiki'ed, and argues this is due to the presence of code like <!-- <ref name="Dummy" />--> (all the nowiki tags are added after that code appears).
Haven't had a chance to test yet.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
There are 2 different issues. One is how Parsoid parses the page (which is different from how PHP parses it this is bug T96555). However, this should NOT cause dirty diffs. And, the reason for a dirty diff is because of a bug in VE.
So, I created a test page, edit it in VE and follow the debugging instructions to dump the DOM before / after edit in VE. Even though I only change an 'a' to an 'A', the DOMs show that VE has dirtied the <ref> tag by adding the html attribute (which is usually only added when a <ref> is edited) which then causes Parsoid to do its damage.
[subbu@earth parsoid] diff /tmp/old.html /tmp/new.html
1c1
< <body id="mwAA" class="mw-content-ltr sitedir-ltr ltr mw-body mw-body-content mediawiki" dir="ltr" lang="en"><p id="mwAQ">a <span about="#mwt2" class="mw-ref" id="cite_ref-1" rel="dc:references" typeof="mw:Extension/ref" data-mw="{"name":"ref","body":{"id":"mw-reference-text-cite_note-1"},"attrs":{}}"><a href="#cite_note-1" style="counter-reset: mw-Ref 1;"><span class="mw-reflink-text">[1]</span></a></span> f</p>
---
> <body id="mwAA" class="mw-content-ltr sitedir-ltr ltr mw-body mw-body-content mediawiki" dir="ltr" lang="en"><p id="mwAQ">A <span typeof="mw:Extension/ref" data-mw="{"name":"ref","body":{"id":"mw-reference-text-cite_note-1","html":"b <!--<ref name=\"c1\" />--> y b &lt;/ref&gt; c &lt;ref name=\"c2\" /&gt; d &lt;ref name=\"c3\" /&gt; &lt;ref&gt;e "},"attrs":{}}" about="#mwt2" class="mw-ref" id="cite_ref-1" rel="dc:references"><sup href="#cite_note-1" style="counter-reset: mw-Ref 1;">[1]</sup></span> f</p>Incidentally, I found another related instance of this VE dirtying behavior in T150196#2811137 ... admittedly both are edge cases, but still this is a VE issue.
I am going to remove the Parsoid tag since we have the Parsoid bug already tracked in T96555 and leave this for VE to tackle. /cc @Esanders @Jdforrester-WMF.