It can now be activated with useparsoid=1; by default, it still fails.

1. <annotation-xml> mspace and there are other invisible content elements such as &InvisibleTimes; &InvisibleComma; &ApplyFunction; and much more. People call math notation sesquidimensional, so it's not always obvious how to extract a 1-dimensional string from it. A hard problem. I don't think you really want to go that route. An alternative would be to use the normalized \TeX input.
2. I expect that everything that generates a server-side uses the codepath that outputs class texterror. Anything else should be considered a bug and reported. merror is the HTML tag for error in math, but it should usually not be generated by the math extension (otherwise that's a bug). Eventually, we should make sure that we use the MW way to express errors if we spot merrors in the MathML output.

I think it's now ready for review. There are quite a few changes https://meta.wiki.beta.math.wmflabs.org/w/index.php?title=Special:MathDebug&action=visualDiff&ref=a9cf8619845965032bd3af3a7dca36b594282eb4&base=99d6135b2451792afc00149dfc5897ed6a8d45c3
It's not fully TeX as we are missing \operatorname*. Production (Restbase/Mathoid) and native MathML both render \operatorname* as \operatorname{*}. Supporting it in native mode can only be done after the Mathoid/Restbase mode was switched off.

I will file a new issue for global font choice. It’s a bit a dilemma as the new version of the old font type is good for regression testing but bad for non latin characters.

@Jacobolus, if it were on me, we would use TeX instead of HTML in the browser :-)
@MSantos, I don't see an action item here. Maybe you want to close this ticket and open a new one about the global font choice.

I can't see what's wrong. For me, it looks as small as in LaTeX

@Osps7 I am happy to review your patch. There are already quite a few tests, for example, for https://phabricator.wikimedia.org/T382669. I would recommend you always compare with LaTeX and try to see how LaTeX does it by reading the LaTeX source, which is less confusing than reading the Stack Overflow comments, which are sometimes a bit off.

@mhchem, could you confirm whether this is expected mhchem behaviour?

Actually it matters if its \ce{\overbrace{\ce{H2O}}} or \ce{\overbrace{\ce {H2O}}}. So I need to have a second look

It seems to be unrelated. This can be easily fixed in the grammar... just need to avoid infinit loops

Checking relation to Parsoid T399226

For the refresh of the math datasets (T439313), MathSearch gives every formula an id from the revision and its position in the source, and stores it in the math index. Both the page view and the maintenance script UpdateMath now get these ids from the MathFormulaPostRenderRevision hook, so links from the index reach the same formula on the page (https://gerrit.wikimedia.org/r/1349809). With the legacy parser this works; with Parsoid it currently works through the legacy fallback.

@Jacobolus, thanks, agreed that this is not limited to the reported pair. The same root cause affected a whole group of symbols, and they were fixed together in Ib88697 (Use data-mjx-alternate for variantForm and alternate). The list of affected commands is in that change. The fix is on master and should reach the wikis with next week's deployment.

I'm stopping work on this for now, since pure Native MathML isn't the focus. WIP patch: I59d0b3

Partly fixed by Ib88697 (Use data-mjx-alternate for variantForm and alternate). \nleqslant and \ngeqslant emit U+2A87 and U+2A88 with data-mjx-alternate. Client-side MathJax now reads the attribute and draws its own negated slanted glyph, which is correct.
Native MathML is still wrong. Browsers ignore the attribute and draw U+2A87 and U+2A88 as written, i.e. ⪇ and ⪈ (\lneq and \gneq).

@Ricardomota In theory, my patch makes some jobs slower, as canUseParserOutputFromCache() now returns false more often. This only affects Parsoid links updates (the default) for jobs without a root timestamp, e.g. the cascade-protection jobs queued by LinksUpdate::queueRecursiveJobs or Wikibase Client. Those used to reuse any cached output of the current revision. Now they re-parse, with the cached output passed as previous output.

@MSantos thanks for sharing

@Krinkle, thanks for checking. Now I see that too, sorry.

@Krinkle did you apply the change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1345667/4/src/WikiTexVC/texutil.json , it's not reviewd and thus not on mw.o

@Krinkle, a finding from testing the \emptyset / \varnothing change (Ib70c43) in native MathML mode.

@Akaza24, there are quite a few issues with the CI pipeline at the moment, and I didn't want to get in conflict with my local draft changes. Thus, I rebased on my latest change. In the end, all that needs to be changed is just these two lines

I updated the patch, and it works locally... however, unfortunately, there are currently failing tests, and the change depends on 6 other changes waiting in the queue before.

@ABreault-WMF thank you. I will just continue with depends-on, but there are not too many changes that will need assistance to pass ci once this is sorted out see https://gerrit.wikimedia.org/r/q/project:mediawiki/extensions/Math+status:open+branch:master

Ah variantform is passed into the DOM as invalid html element, that is why the fix of @Akaza24 worked

From the source

	"\\O": {
		"nullary_macro_aliase": "\\emptyset"	
	"\\empty": {
		"nullary_macro_aliase": "\\emptyset"
	"\\emptyset": {
		"identifier": [
			"∅",
			{
				"mathvariant": "normal"
			}
	"\\varnothing": {
		"ams_required": true,
		"identifier": [
			"∅",
			{
				"variantForm": "true"
			}

@Akaza24 can you post some screenshots? I would think that we just need to change the entry in the texutil.json

Aside: as a feature request, it would be nice if all of the Wikipedia LaTeX renderers supported some command(s) along the lines of those provided by the scalerel package. There are several relatively common notations which are currently impossible to show correctly in Wikipedia because of the inability to resize symbols.

@Jakob_WMDE thank you very much. With your guidance, I was able to reproduce the problem locally and improve your core patch. If you have any idea who could review it, I would highly appreciate your suggestions.

@Jakob_WMDE is that only a problem for Math or for any Wikibase test run?

@Jakob_WMDE sorry, I wanted to post to https://phabricator.wikimedia.org/T418086, but after looking into that now, it also doesn't seem to fit too well. I'll investigate a bit further and create a new ticket.

Thanks, that sounds like a better place to fix it. I don't see how to do it myself, though: MediaWikiServices::disableStorage() redefines DBLoadBalancerFactory as LBFactorySingle::newDisabled(), and the database and tables tasks still need a working factory before AddWikiRestoredServicesProvider restores the services. I'm probably missing something.

The patch was originally created to generate a 750GB disk for qlever.

@fgiunchedi I discussed the GDPR and privacy issues with @EgonWillighagen and others, and we reached a consensus that it's better to focus on external hosting (including qlever.dev). I am thus shutting down the wikiqlever project