In T228217#5355528, @Arlolra wrote:

Trying to address T178914: parse.js should have standard arguments as part of this port might be something worth considering.

I could address the specific points mentioned there, but I would rather not be on the hook for coming up with a holistic vision

Trying to address T178914: parse.js should have standard arguments as part of this port might be something worth considering.

In T215000#5348462, @gerritbot wrote:

Change 524385 had a related patch set uploaded (by Subramanya Sastry; owner: Subramanya Sastry):
[mediawiki/services/parsoid@master] Work around PHP DOM's failure to normalize DOM during DOM build
https://gerrit.wikimedia.org/r/524385

In T114432#5354637, @daniel wrote:

@cscott this RFC seems close to an agreement. Implementation is probably blocked on php-parsoid, but the new syntax and semantics could already be approved.

In T228069#5352568, @Joe wrote:

Can I ask why such parser tests will need to run in production rather than via the CI infrastructure? CI can reach the production wikis via the public interface, so I don't see a reason to keep perpetraring the off-standard thing we have with scandium, unless there are specific reasons to do so.

In T130689#5351169, @Aklapper wrote:

@Renxiaoyi: Hi! You assigned this task to yourself a while ago. Could you maybe share a status update? Are you still working (or still plan to work) on this issue? Or is there anything that others could help with? (If you do not plan to work on this issue anymore, please remove yourself as assignee (via Add Action... → Assign / Claim in the dropdown menu) so others could work on it.) Thanks a lot!

In T228346#5347642, @Smalyshev wrote:

Do we have some small piece of code that we can demo this problem?

In T228217#5347064, @Arlolra wrote:

genTest is not relevant in the post-javascript world, so I'm crossing those off

FYI: This bug doesn't show up with PS6 of gerrit 523715. So, you need PS5 of that patch.

All in ParagraphWrapper token transformer code.

In T134469#5342157, @cscott wrote:

Unfortunately (?) Parsoid is now bug-compatible with PHP in this regard (example from T227953):

See https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/523845

It looks like the KV[] scenario is from https://github.com/wikimedia/parsoid/blob/a66aad7d6697447300a08ca24c0c246f9ac84068/src/Wt2Html/Grammar.pegphp#L274 (same on the JS side). The reason why we might not have tripped over this in tokensToString is probably because ext-tokens never hit this code path. But yes, we should probably add asserts to both JS & PHP side to ensure we catch unhandled scenarios early.

The problem is with the code that generates the DOM to which the selectors are applied, Zest output is correct for the provided dom.

In T227921#5334508, @matmarex wrote:

The {{Collapse bottom}} template generates the |}, and for it to work correctly as an end-of-table markup, it must be on a separate line. In the diff you linked, it was placed by Parsoid on the same line as the closing </syntaxhighlight> tag.

PHP parser tests script is almost ready, and so this is no longer necessary.

In T227216#5305502, @ssastry wrote:

In T227216#5305441, @ssastry wrote:

These steps will probably work on any production wiki as well.

Yes, confirmed on [[enwiki:Hampi]]. Now, waiting for deploy to complete before I can re-try that and verify it is fixed.

In T227216#5305441, @ssastry wrote:

These steps will probably work on any production wiki as well.

Instructions from @cscott to reproduce this bug:

1. https://en.wikipedia.beta.wmflabs.org/wiki/Martyrs_of_Gorkum?veaction=edit
2. click VE 'cite' button, insert manual citation.  i used "website", then URL "https://cscott.net" and title "title"
3. now switch to wikitext editor, confirm inserted reference is sane
4. now switch back to VE, click the reference, click edit.
5. the url will be corrupt

@SUM1, Thanks for your help .. we may have found some leads to track this down.

In T227216#5305238, @SUM1 wrote:

@ssastry I'm back at a standstill, can't reproduce the bug again. I'll keep testing.
And not yet, but I can go searching for affected edits.

In T227216#5305234, @SUM1 wrote:

@ssastry The reporting user didn't experience the bug herself (to my knowledge) but encountered numerous other people's edits being affected.

@SUM1, can you let us know if the reporting user was switching back and forth between Wikitext and VisualEditor?

@cscott: one way to narrow this down is to run the deployed version of Parsoid on the revision that was edited and try a selser edit.

In T227216#5305039, @cscott wrote:

It's *possible* that VE is to blame, if for some reason it's not marking subtrees as 'changed' properly, but I agree that this is probably a Parsoid selser bug.

In T226692#5301001, @ssastry wrote:

In T226692#5300978, @ssastry wrote:

This bug should have been fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ParsoidBatchAPI/+/517479 ... but, maybe that hasn't been deployed to production yet? Or, maybe refresh that page to check?

https://www.mediawiki.org/wiki/MediaWiki_1.34/wmf.10/Changelog#ParsoidBatchAPI says this went out in wmf-10 .. so, let me refresh that page.

In T226692#5300978, @ssastry wrote:

This bug should have been fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ParsoidBatchAPI/+/517479 ... but, maybe that hasn't been deployed to production yet? Or, maybe refresh that page to check?

This bug should have been fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ParsoidBatchAPI/+/517479 ... but, maybe that hasn't been deployed to production yet? Or, maybe refresh that page to check?

Given our goal of wanting to run parser tests independently in this code base without having MediaWiki checked out and integrated, it makes sense to port our JS runner. The core runner has tighter integration with MediaWiki internals and isn't suitable if we are serious about the isolation goal. If at a later point, this goal is no longer relevant, we can revisit.

@Kelson. Sorry, I didn't imply this wasn't a bug. I did say this is a ChangePropagation issue and tagged @Pchelolo and @mobrovac and asked them to reopen / file a diferent ticket. But, yes a better solution would have been to untag Parsoid and MCS and tag ChangePropagation, which I am going to do now. Thanks for following up and apologies for my confusing triage.

https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/519727 fixes some more.

https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/519537 fixes 4 tests.

https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/519523 fixes that.

Шаблон:Неиспользуемые_шаблоны oldId 96001852 on ruwiki

At this point, I am tempted to say, this is pretty much a won't support scenario. Ideally, we would detect this wikitext pattern and flag it for wikis to fix their wikitext so that code can be supported unless of course this usage is very common practice. But, given that it has taken these many years for someone to notice this breakage indicates that this is likely not very common. If we want to proceed down the path of independent parsing futures, [[ {{template}} ]] will only parse as a link in the case where {[template}} yields a valid link (which we currently support). But if the templateyields pieces of syntax that has to be combined with other syntax from the top-level page that then happens to resemble a wikilink, then that is not something we want to encourage and support going forward.

Now that we have a php parse script, we can run wt2html and html2wt entire in PHP without needing to rely on hybrid testing. Hence lowering priority. But, till T224680 is resolved, hybrid testing is useful for running parser tests.

This is probably some old bug that just got lost in the noise of other ignoreable log reports. We should seriously kill a lot of our non-actionable logspam (error/lint, error/lint/api, warn/*).

See 159 of these instances in the last 24 hours.

TypeError: Cannot read property 'nodeName' of undefined
    at Object.getWrapperTokens (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/src/lib/utils/PipelineUtils.js:354:18)
    at Object.encapsulateExpansionHTML (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/src/lib/utils/PipelineUtils.js:477:28)
    at Object.tunnelDOMThroughTokens (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/src/lib/utils/PipelineUtils.js:586:24)
    at DOMFragmentBuilder.wrapDOMFragment (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/src/lib/wt2html/tt/DOMFragmentBuilder.js:105:30)
    at DOMPostProcessor.documentCB (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/src/lib/wt2html/tt/DOMFragmentBuilder.js:96:30)
    at emitOne (events.js:101:20)
    at DOMPostProcessor.emit (events.js:188:7)
    at DOMPostProcessor.<anonymous> (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/src/lib/wt2html/DOMPostProcessor.js:723:7)
    at next (native)
    at tryCatchNext (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/node_modules/prfun/lib/index.js:783:28)
    at continuer (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/node_modules/prfun/lib/index.js:800:24)
    at callback (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/node_modules/prfun/lib/index.js:812:43)
    at tryCatch1 (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/node_modules/babybird/lib/promise.js:40:12)
    at promiseReactionJob (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/node_modules/babybird/lib/promise.js:269:19)
    at PromiseReactionJobTask.call (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/node_modules/babybird/lib/promise.js:284:3)
    at flush (/srv/deployment/parsoid/deploy-cache/revs/a8d9f6e0b6a7e61684fffbdac897473b9acf2f82/node_modules/asap/raw.js:50:29)
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

Tangential to the actual bug report, given that mw:Param is only inserted for top-level {{{..}}} that can't be expanded and hence is emitted as is, not sure why Parsoid html2wt insists on data-mw for this case.

In T225217#5253555, @matmarex wrote:

This should be resolved by the Parsoid patch and now we're just waiting for the next Parsoid deployment, correct?