Last modified: 2013-09-19 19:03:07 UTC
https://en.wikipedia.org/w/index.php?title=Northrop_Loom&diff=562756829&oldid=543023104 added matching nowiki tags, but the change didn't actually include any markup - or, well, anything (it was an attempt to add a comma, which hasn't appeared).
Belay that; comma appears, I'm just blind :). Still no reason for the nowikis I can see.
Original problem occurred on Firefox on Windows 7. I didn't replicate it, but another editor did with Chrome on Windows 7: http://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FNL&diff=562864059&oldid=562863922
This is reproducible; if you edit the original in VE https://en.wikipedia.org/w/index.php?title=User:Edgepedia/VE/NL&oldid=562863922&veaction=edit and make no changes it clean-diffs (selser to the rescue), but if you try to replicate the edit (add a comma anywhere in the paragraph after the "Economics" heading), the text following the multi-line HTML comment is escaped in <nowiki>s.
Simplified test case. Run this through wt2wt in Parsoid. " bar" will be nowiki escaped, but " foo" will not be. <!-- --> foo x <!-- --> bar If you parse the above wikitext (ex: paste it in enwiki sandbox) " foo" will be rendered as preformatted text but " bar" is not. Parsoid handles that correctly. But, the multiline comment followed by a space trips Parsoid's nowiki insertion code when converting the html to wikitext. It doesn't realize that " bar" will not be preformatted because the the comment did not start at the beginning of the line many lines up. We'll look into this, but I suppose this is not a very common occurrence.
*** Bug 52266 has been marked as a duplicate of this bug. ***