Context

Currently, the Math extension is supported during Parsoid parses by the implementation targeting the legacy parser. This does work, except for the fact that every invocation of Math is independent during a Parsoid parse, which currently makes it impossible to take advantage of the MultiHttpRequest that is used to batch multiple requests to Mathoid.

T268785 suggests moving the parallel parsing logic to core, which would clean up this mechanic and make it re-useable for other extensions. We could then imagine a way to plug that into a Parsoid-targeting implementation (although it's not entirely clear how).

Task

This task considers a different and smaller scope, namely "create enough enough of a Parsoid-targeting implementation to support the parallel Mathoid requests used in the legacy-targeting implementation. The scope of this task is limited to this specific use case (almost: see caveats section) and does not intend to create a full Parsoid-targeting implementation of the Math extension".

How

The idea would be to implement some Parsoid tag handling inside the Math extension. We foresee it would require the following:

• an ExtensionTagHandler, implementing the sourceToDom method. This would replace the invocations to the Math extension requiring a batch processing by a placeholder, typically a <meta> tag containing the relevant information.
• a DOMProcessor, implementing the wtPostprocess method. This would traverse the tree generated by previous invocations, gather all <meta> tags, create the corresponding batch queries and replace the elements with the final rendered elements, in the same way the parserAfterTidy does it for legacy.
• the extension would only register the tag (via ExtensionModule::getConfig) when it is needed - i.e. when $wgMathSvgRenderer === restbase.

Caveats

• The exact rendering mode can depend on the user preferences, passed to the parser via ParserOptionsRegister. This is fine, but we do not currently pass ParserOptions to the ExtensionAPI - this needs to be discussed. As a first step, handling this unconditionally with a large TODO is good enough for the first version of the patch (not necessarily for the first *merged* version of the patch, though.) Note that, a priori, we do NOT want to handle the *loading* of the extension depending on the user preferences: this would split the cache on user preferences whether the page has Math content or not.
• $wgMathSvgRenderer is also controlling the rendering via mathmlcli, which *also* has a batch processing mechanism, which would be good to handle as well. (This is the second use case that we swept under the rug in the "task description" section.)
• the Math extension also defines a couple of hooks, which are then used by MathSearch, and pass a parser to them. There are things to be discussed there as well (most probably: modify the hooks so that they do not pass a full parser, which it seems they only use to get a revId; to be confirmed with more investigations.)