Thu, Jan 18
Another case where the lack of extension content sanitization is biting us.
Fri, Jan 12
I see now
Thu, Jan 11
Nope, that change only had an effect in the presence of a SOL-transparent template. This bug is about the ordering p-wrapping and treebuilding in Parsoid.
we got an interesting regression reported by @jeroen that I just managed to reproduce with this test case and the amended commit. It shows that the output data is somehow repeating after the first 16K!
Wed, Jan 10
It certainly seems like what's being POSTed is fine, but we verified in T183356#3877500 that what's received is already corrupted. Is there any proxy sitting in between the two?
Yes, still active. The figure-inline changes to Parsoid's output got lumped in with a bunch of other things that took some time to deploy. I will be picking this up again something soon. Thanks.
Tue, Jan 9
Mon, Jan 8
Confirming that https://en.wikipedia.org/api/rest_v1/page/html/Wikimedia_Foundation/803552163 is not wrapped in the span
Fri, Jan 5
I did not see output in CLI otherwise.
Thu, Jan 4
Similar to T183701 in the sense of the scope of the transclusion, but ...
There's a discussion of DOM scopes in T118110
however, the response looks like a conflation of Parsoid's html and the php parser's output.
Hmm, guess that wasn't it?
Hmm, it's throwing on,
Wed, Jan 3
To me, it looks fine at this point.
Closing since the patch merged. I will confirm the fix after the next deploy.
Tue, Jan 2
Thanks. 50 paragraphs of plaintext should not cause any problems.
Fri, Dec 22
Thu, Dec 21
Dec 21 2017
Do you have an example of the test you're using? Please put it in a paste somewhere.
Dec 20 2017
Dec 19 2017
Dec 15 2017
With that merged patch, the page parses in ~22s and the render seems reasonable now. The roundtrip test also works for me.
Dec 13 2017
requests posting wikitext are being stored as the latest render.
Briefly, Parsoid only has that meta info for the head when it fetches the page source itself to parse. This seems to indicate that requests posting wikitext are being stored as the latest render.
Dec 12 2017
Another example confirming what was implemented,
Dec 11 2017
Tentatively going to try closing this.
Dec 8 2017
The problem seems to predate that patch. A new paragraph begins after the <div> closes but before a </span>gets a chance to closes as well.
Dec 7 2017
Dec 6 2017
A couple of edits since the deploy that seem to be putting things in the desired order,
A test edit on https://de.wikipedia.org/wiki/Einwohnerentwicklung_von_Jena?oldid=170950445&veaction=edit puts the table end tags on their own lines now.
We now get the expected render at https://ru.wikipedia.org/api/rest_v1/page/html/%D0%A5%D1%80%D0%BE%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_%D0%BF%D0%B5%D1%80%D0%B2%D1%8B%D1%85_%D0%BA%D0%BE%D1%81%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85_%D0%B7%D0%B0%D0%BF%D1%83%D1%81%D0%BA%D0%BE%D0%B2_%D0%BF%D0%BE_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B0%D0%BC
Nov 30 2017
Is it? The table w/o the closing tag was edited in those cases. Broken being the operative word.
Nov 27 2017
Possibly related to about group re-parenting (T176425).