Last modified: 2014-08-27 14:50:26 UTC
Parsoid appears to be adding a newline after templates that are followed by inline text. This has unfortunate results if the first character after the template is a space, as then the following text is rendered as if it were inside <pre></pre> tags. Example: https://en.wikipedia.org/w/index.php?diff=621410250 That example is an edit generated with [[User:Jackmcbarn/editProtectedHelper]], which uses Parsoid to deal with Wikitext. See https://en.wikipedia.org/w/index.php?diff=621243755 for an example of how the tool normally works. This seems to be related to, but not quite the same as, bug 68862.
Parsoid doesn't add newlines after templates that are followed by inline text. See http://parsoid.wmflabs.org/enwiki/Template_talk:Portland,_Oregon_weatherbox?oldid=621304124 where you can see that the leading space doesn't render as a pre. This is not related to bug 68862. This seems to be a problem with html->wt serialization after EPH edited the HTML and asked Parsoid to generate wt for it. That said, I have tried various kind of edit scenarios and I cannot reproduce this locally. This is either some subtle serialization bug, or EPH made an unrelated modification to the DOM that triggered the newline break there. Despite all that, what is curious is why Parsoid's html->wt serializer didn't protect the leading space with a nowiki in any of these edit scenarios (which is what I am seeing locally in all my tests). In any case, this is yet another instance of our paragraph-wrapping differences compared to the PHP parser. Implementing a fix for bug 64901 would have prevented this specific error because the inline text would have been wrapped in a paragraph-tag and would have been serialized correctly. I am not merging this as a duplicate of bug 64901 just in case we want to try and figure out what happened here with the html2wt pipeline.
