I don't have a lot of experience with MathJax so I was able to get linebreaks working with <math display="block"> (first and fourth example from the image) but not with :<math> or :<math display="inline">:

On the linked patch demo you can see the fix in action if you log in as Alice (password: patchdemo1) and view the main page on the mobile view:

I can reproduce this by changing my preferences to MathJax rendering, enabling the preview without reloading the page, then previewing the page twice. On first preview, the formula displays correctly, on second preview I only get MathML.

I rebased the patch to GlobalUsage and I can carry on additional changes until it's satisfactory for merging. But since it's been 20 years since this bug was opened, I was curious what are the fundamental reasons such a patch might be undesirable, in case further discussion is needed?

I'm seeing several tasks lying around specifically about CORS issues with MultimediaViewer:

This line seems to be gone as a result of T426217: MediaViewer downloads high-res image twice if thumb URL is re-used / this commit. Good to close?

Right, sorry, I see what you mean. The link becomes purple when clicked, but if you visited the page from some other source before it wouldn't have turned purple, because of the different URL normalization on Parsoid.

I'm seeing a visited link in both Chrome 147 and Firefox 150 on Linux, and latest Firefox for Android, despite the space in the URL.

PortableInfobox is still incompatible with Parsoid, and while Original Authority's linked pull request goes a long way, I wanted to make a few notes on issues we encountered on Undertale/Deltarune Wiki when rolling out Parsoid for read views.

As Krinkle pointed out in T276737: mw.util.getUrl using params should use short urls if they exist, it's not a bug with mw.util.getUrl. It is indeed supposed to return paths relative to $wgScript when query parameters are passed, which ensures the generated URL is excluded by robots (in the Wikimedia environment). Other components that generate URLs with wprov in the same way that my change proposes are:

Adding the Interwiki and API projects because the root causes of this bug are:

I assume there's no need to remove the rule from MinervaNeue now, and the issue seems to be fixed.

Makes sense. We deal with robots by specifically excluding action, diff, oldid and similar parameters in robots.txt, but I get that you would have to track whenever a new parameter appears and (remember to) exclude it from robots.txt.

This is causing a minor inconvenience for us at the Undertale/Deltarune Wiki, since our analytics software is tracking page visits by URL, and all article visits through RelatedArticles get segmented separately from the rest of the visits because RelatedArticles adds wprov=rarw1 (which I assume stands for "Wikimedia provenance") to the page URL, turning it from a pretty URL back into an index.php URL.

This has now been fixed.

Can't create a patch demo, but I tested the change on a development version of Deltarune Wiki:

This filter:

(action == "delete" & page_prefixedtitle == "File:Example.png") |
(action == "move" & moved_to_prefixedtitle == "File:Example.png")

does not prevent the behavior I'm referring to either. The abuse log generated by attempting to move the page over the other page shows action as delete, but the file itself remains deleted.

I figured out this is due to ClassicInterwikiLookup::getAllPrefixes() never returning interwiki prefixes from virtual domains, which, in turn, makes the siteinfo API module never return these prefixes, and so Parsoid never fetches them from the API. Which is odd, because ClassicInterwikiLookup::fetch() does fetch interwiki prefixes from virtual domains, and SpecialInterwiki has its own fetching of interwiki prefixes from virtual domains.

I see. Should I open a separate ticket and send a new patch?

Users with a selection of 20 different templates are supposed to look at their icons and titles and select the template they need. Why wouldn't they be able to do that? If the icons and titles are unclear, that's the fault of the wiki admin who configured the templates.

Yeah, it seems to still work when I apply the patch from r1188860 to REL1_44.

I tested this out, and it works great! Any chance it gets cherry-picked to REL1_44?

For what it's worth, we hit this limit today on Deltarune Wiki with our 7 citation templates. Could this perhaps be made configurable? Can make another patch myself if so.