RT-testing was run one commit earlier on 4c9636e9b2; 9db4b8f34 is a codesniffer and eslint update, so that doesn't change anything for rt-testing.

I believe we want to compare these two:

• https://en.wikipedia.beta.wmcloud.org/wiki/Help:MathTest?mathmode=mathml
• https://en.wikipedia.beta.wmcloud.org/wiki/Help:MathTest?mathmode=mathjax

I suspect that is indeed the diff you ran, but I want to double check just in case :)

As I understand it:

• in mathoid mode, we send the TeX directly to mathoid and let it do its thing (as I understand it: ship it to mathjax, which handles the full TeX->MathML->SVG conversion)
• in mathjax mode, we convert the TeX to MathML, and that's what we ship to mathjax-client-side.

Okay, I have run said visualdiff. It's not catastrophic and significantly better than mathml, BUT I wouldn't call it parity.

I'll run a visualdiff on https://en.wikipedia.beta.wmcloud.org/wiki/Help:MathTestNative and we'll see where we're at (this looks pretty comprehensive).

As far as I can tell, this was fixed. (Took me a little while to establish that " was not authorized as a character in URLs for external links - that's in https://www.mediawiki.org/wiki/Help:URL.)

Should it, though? It's not obvious to me... For one thing, converting "something.png" with sr-cyrl rules, for instance, wouldn't yield something that makes sense? I don't know, maybe I'm oversimplifying the matter, but a file name is a file name, it doesn't feel like it should be converted for redlink handling.

As far as I can tell, this is a feature request. The code as it currently works gets a document model of the wikitext, extracts the requested section, and parses the result as an independent document - hence the fact that we lose the numbering of the sections in this call.
The one thing that makes me doubt (and that's a complicated question on an issue open 5 years ago) is "causing the edit links to open the wrong section" - which I think might have been an unrelated issue.
I think this goes to ContentHandler; keeping that for us because I don't have a better candidate right now, but putting this on Later.

This has not triggered since May, let's assume it's fixed.

Reproducer that doesn't involve DT in any way:

I can't find this in logs anymore, and there's been significant changes in this area since then. Closing as not relevant anymore.

This hasn't triggered in the past 2+ weeks - I'm going to assume that whatever was triggering this has been fixed (this was a fairly short spike, with a few lingering that might have come from cache). If not, we'll re-open this.

Can confirm that this is still triggering on https://sk.wikipedia.org/w/index.php?title=Zoznam_SD_objektov_2&oldid=6558488&useparsoid=1; https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1295478 that apparently fixes T426525 does not fix this one.

Hrm. This comes from the fact that expanding {{PAGENAME}} goes through CoreParserFunctions::pagename, which does escape wikitext on output.
At this point, we get the ' added to the string that gets parsed by Parsoid; and when we encounter an explicit entity on parsing, it gets wrapped inside a mw:Entity span for, as @Izno points out, round-tripping reasons. So its generation looks correct to me.

There doesn't seem to be a lot to go from with this message - I can't really see any kind of pattern apart from the obvious (the messages with the same error message come from the same place that define the error message ;) ). As far as I can tell, this is roughly 500 hits in the last 24 hours; it looks ~mostly consistent over the past three months (maybe a vague increase since mid-may? Hard to tell for sure, I haven't run stats) apart from a couple of peaks that can probably be discarded as outliers.

I've also edited the page that triggers the issue, now that we have a reproducer.

Reproducer:

<ref>[http://ww{{s-start}} {{some template}}w.example.com test]</ref>

I did manage to reproduce a reasonable path that does lead to this issue: if you open a MessageBundle, and edit the JSON, create invalid JSON (either bad syntax or not passing the validation), and click on Preview, it will trigger this issue (and crash violently). So I agree with @Pppery above - adding an error message as is done in the other patch looks like a reasonable approach.

@Kallichore ah, fantastic, thanks you :)
(I was quite disheartened when the first patch that was working on my setup didn't fix the issue in prod :D )

Some debugging - rev1.html is the result of wt2html parsing, rev2.html is an edit that adds a string to the paragraph. It round-trips correctly, while it doesn't when VE is involved (direct edit on my local wiki).

(Edit tested on testwiki post train branch cut)

In T428949#12059522, @Reedy wrote:

Just to note T428911: Formally EOL MW 1.44 and that that is due end of July 2026, so how much time and effort you want to put into this for REL1_44...

Fixed on https://fr.wikipedia.org/wiki/Gare_de_Moret-Veneux-les-Sablons for this specific issue.

Closing this one as T428948, T428949 and T428950 have been created for said backports.

This is due to the fact that the wrapping happens before DOMFragments are unwrapped; and in this case, the DOMFragment contains the category and the text, but is stored inside a category link:

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1304061 should fix the DT one (T429582) and can be backported to .wmf.7.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/1304061 should unblock the train. (ignore the other patches - they're at best WIP attempts to fix the actual issue, but the DT patch fixes the symptoms at least)

The issue looks like it's around
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/libs/JsonCodec/+/refs/heads/main/src/JsonCodec.php#376

Current investigation: this thing SHOULD be an array, and it seems to be in most cases, BUT sometimes an empty stdClass sneaks in there. Looking for "why".

Now whether the span removal belongs to Parsoid or to Charts, that's another question that requires a bit more thought, probably. (I'm leaning "Charts", but I need to look into where that happens in a bit more detail.)

I'm reasonably convinced that the issue is something around the following:

• when parsing the strings, Parsoid inserts some <span typeof="mw:DisplaySpace"> </span>% in there
• these are not removed before we try to put them in the svg tag
• something somewhere goes "a span? not in MY svg!!", closes the SVG before the span, and then things go badly from there.

Is this still an issue? I can't manage to reproduce it (the initial page doesn't seem to have a map anymore; https://en.wikipedia.org/w/index.php?title=Tyre,_Lebanon is the one I've been looking at); and https://html.spec.whatwg.org/#srcset-attribute seems to argue that as long as URLs do not start or end with a comma, they should be fine with having inner commas. I've checked that I do get the 2x image on higher DPI screen, and it doesn't look like it breaks, at least on Chrome (I don't have a Safari device on hand.)