Test Steps

Status: ✅ PASS
Environment: enwiki
OS: macOS (Chrome) and Windows 7 (Chrome)
Browser: Chrome
Device: MS

⸻

Test Case 1: Verify horizontal scrollbar on Chrome macOS

1. Visit https://en.wikipedia.org/wiki/Fibonacci_sequence on a Mac running Chrome.
2. Scroll to the Decomposition of Powers section containing the long math sequence.
3. ✅ AC1: Confirm that a horizontal scrollbar is visible for the long math equation.

Test Case 2: Verify horizontal scrollbar on Windows 7 Chrome

1. Using BrowserStack or an equivalent tool, open https://en.wikipedia.org/wiki/Fibonacci_sequence in Windows 7 with Chrome.
2. Scroll to the Decomposition of Powers section containing the long math sequence.
3. ✅ AC2: Confirm that a horizontal scrollbar is visible for the long math equation.

While we're at it, as you can see from Edtadros's screenshots above, the vertical alignment of inline math is also off, worse than it was yesterday.

Edit: there have been complaints about block math rendering at
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#math_display=%22block%22_is_broken
and
https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Mathematics#math_display_block?

Please revert ASAP, since it breaks many WP articles (examples).

And why WMF doesn't have standard tests cases that will catch such obvious bugs (like this and T387543/T388197) before they are deployed everywhere and break all Wikipedias? Even WP templates usually have /testcases subpages...

There is no need for further comments unless you are actively helping fixing things. It just slows down the process by taking away focus. It seems there was a problem with the visual tests we use so I've raised T391124: Pixel missed a visual regression due to a change in test. We are aware of issue and looking into a fix.

In the mean time this can be worked around in two ways:

• Switch to MathML rendering https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering-math
  • Edit the page to force onto new lines https://en.wikipedia.org/w/index.php?title=Pi&diff=1283938085&oldid=1283399385

Now back to fixing the issue:

Repeating my question above so it doesn't get lost:
@Physikerwelt for MathML display="block" is output on the parent element, but no equivalent exists for the img fallback (we're putting a block element inside a span which is not ideal)
I think we need to add a class mwe-math-element-inline or mwe-math-element-block to the existing mwe-math-element element to workaround this. I don't see another way to do this, so perhaps this could be coupled with the change to wrap math elements? My sense is the status quo is better than fully reverting the change, as the Math equations were not readable before and at least now even if they are in the wrong position they are?

The inconsistent defaults are also making this harder to test given logged out users are being served MathML so I do think beta cluster should strive to replicate production, so I think this discrepancy should be fixed sooner than later by rolling out MathML to Wikipedias or rolling back beta to the img markup. What do you think?

In T201233#10713566, @Jdlrobson-WMF wrote:

• Edit the page to force onto new lines https://en.wikipedia.org/w/index.php?title=Pi&diff=1283938085&oldid=1283399385

This creates a paragraph break, which is semantically (and visually) wrong, see T182041. The advice to mangle many articles instead of reverting a single buggy commit look very strange.

My sense is the status quo is better than fully reverting the change, as the Math equations were not readable before and at least now even if they are in the wrong position they are?

No, the problem this change was supposed to solve was appearing rarely, but now the "solution" harms a huge number of articles and incites editors to use wrong markup — inserting a paragraph break, as you suggest, or using the (rightfully) discouraged : <math> approach.

In the mean time this can be worked around in two ways:

With all due respect, this is an absurd and unacceptable response. The MathML renderer is completely unready for production use, and its creators seem uninterested in listening or responding to community feedback. Adding line breaks around every piece of block math across Wikipedia is completely unworkable. You are talking about probably tens of thousands of pages, and you want to force someone to change all of their markup on the spot (to be semantically incorrect) and then later change it back when a fix is available, as a workaround to a bug that was just carelessly introduced yesterday. That's an incredible amount of pointless make-work foisted onto volunteer editors who don't have any spare bandwidth for it.

The obvious professional software development solution to this kind of problem is to roll-back the recent change and then fix the bug at your leisure.

There is no need for further comments

This reads as "Shut up, peasants."

The MathML renderer is completely unready for production use, and its creators seem uninterested in listening or responding to community feedback.

This is incorrect. As everyone can see on Phabricator, several bugs have been fixed.

The judgment when something is ready for production is quite subjective.

The "in the mean time" workaround should be to immediately revert this change until it works correctly without breaking the formatting on thousands of Wikipedia articles. We are already seeing some editors who should know better introduce semantically-wrong markup to workaround this, on featured articles no less: https://en.wikipedia.org/w/index.php?title=Pi&curid=23601&diff=1283938085&oldid=1283399385 . Those bad changes will become nearly-invisible causing them to last much longer than this bug, and the longer this breakage goes on the more of them there will be. Please revert immediately.

In T201233#10713896, @DavidEppstein wrote:

The "in the mean time" workaround should be to immediately revert this change until it works correctly without breaking the formatting on thousands of Wikipedia articles. We are already seeing some editors who should know better introduce semantically-wrong markup to workaround this, on featured articles no less: https://en.wikipedia.org/w/index.php?title=Pi&curid=23601&diff=1283938085&oldid=1283399385 . Those bad changes will become nearly-invisible causing them to last much longer than this bug, and the longer this breakage goes on the more of them there will be. Please revert immediately.

I agree

@Physikerwelt for MathML display="block" is output, but no equivalent exists for the img fallback.
I think we need to add a class mwe-math-element-inline or mwe-math-element-block to the existing mwe-math-element element to workaround this. I don't see another way to do this, so perhaps this could be coupled with the change to wrap math elements?

We could check if it’s a div —> block or a span —> inline

In T201233#10713570, @Jdlrobson-WMF wrote:

Now back to fixing the issue:

Repeating my question above so it doesn't get lost:
@Physikerwelt for MathML display="block" is output on the parent element, but no equivalent exists for the img fallback (we're putting a block element inside a span which is not ideal)
I think we need to add a class mwe-math-element-inline or mwe-math-element-block to the existing mwe-math-element element to workaround this. I don't see another way to do this, so perhaps this could be coupled with the change to wrap math elements? My sense is the status quo is better than fully reverting the change, as the Math equations were not readable before and at least now even if they are in the wrong position they are?

The inconsistent defaults are also making this harder to test given logged out users are being served MathML so I do think beta cluster should strive to replicate production, so I think this discrepancy should be fixed sooner than later by rolling out MathML to Wikipedias or rolling back beta to the img markup. What do you think?

The overall goal would be to have MathML with optional MathJax enhancements. For now we should revert and redo once images are history. There is at least one problem which seems to require a core fix

https://phabricator.wikimedia.org/T382267

I guess this is related to the issue at hand.

In T201233#10714102, @Physikerwelt wrote:

We could check if it’s a div —> block or a span —> inline

math should never create a div, see T182041.

In T201233#10714126, @MikhailRyazanov wrote:

In T201233#10714102, @Physikerwelt wrote:

We could check if it’s a div —> block or a span —> inline

math should never create a div, see T182041.

Oh. I forgot this. Without div containers scrolling gets harder. I think we should really try to avoid wrapping Math into anything.

Change #1134296 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Math@master] Revert "Take 2: Large math formulae should be scrollable"

https://gerrit.wikimedia.org/r/1134296

Change #1134297 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Math@master] Add mwe-math-element-inline class to all Math elements where applicable

https://gerrit.wikimedia.org/r/1134297

Change #1134298 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Math@master] Take 3: Large math formulae should be scrollable

https://gerrit.wikimedia.org/r/1134298

math should never create a div, see T182041.

Interesting... so that's why we have this bug in the first place. I see T134281: Page becomes horizontally scrollable with certain formulae fixed this and when we moved away from the div in T182041: Display math generates div inside of paragraph (HTML5 violation) we inadvertently broke it.

@Physikerwelt I've proposed a chain of patches to roll back and then roll forward with a new fix. We can look to get those in early next week. I've submitted a new chain of patches to address the new issue and the existing issue and am working on improving the UI regression tooling in T391124: Pixel missed a visual regression due to a change in test

To clarify since the spirit of my last message seems to have been extremely misunderstood:

• We can and should revert this - I don't think there has ever been any disagreement here and @Physikerwelt has agreed in T201233#10713967
• When I said "in the mean time" that was referring to a few days and in the spirit of working around the issue while we fix it.
• We typically avoid reverts on Fridays if we can given it increases the likelihood of people having to take time out of their weekend (and I can't commit to being around this weekend for follow up). If someone wants to do that today, has deploy rights and can be on call, feel free.
• Math in Wikipedia is predominately supported by volunteers and I certainly don't expect them to be on call over the weekend but I defer to @Physikerwelt for what makes sense about urgency of rollback / fixing this particular issue.
  • My 2 cents is that the article is still readable with/without inline and doesn't meet the holding back the train criteria. I suspect the majority of readers won't notice a difference (I honestly didn't but I am not a power user of Math articles). On the other hand, long equations cannot be read at all on mobile devices which seems like a less common but more significant issue.
  • I should be able to help out with the revert early next week. Let me know.

Math articles are still vaguely readable with this bug, but thousands of them have messed up formatting, in some cases pretty severe, and it's hard to get a good sense of what the appearance will be (once the bug is fixed) which slightly hampers editing in the mean time. If it takes two or three days to roll this back it's not the end of the world, but the faster the better.

Once that is done, is there any way we can make up a better set of regression tests to avoid similar kinds of bugs in the future? What kind of testing was done before these changes were pushed, and why wasn't this caught in tests?

Change #1134296 merged by jenkins-bot:

[mediawiki/extensions/Math@master] Revert "Take 2: Large math formulae should be scrollable"

https://gerrit.wikimedia.org/r/1134296

@Jacobolus it sounds like this should have been caught by an existing test, but a regression in the test-runner itself made the test incorrectly pass because it only compared the first screen of test cases. See: T391124.

Change #1134391 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Math@wmf/1.44.0-wmf.23] Revert "Take 2: Large math formulae should be scrollable"

https://gerrit.wikimedia.org/r/1134391

Change #1134391 merged by jenkins-bot:

[mediawiki/extensions/Math@wmf/1.44.0-wmf.23] Revert "Take 2: Large math formulae should be scrollable"

https://gerrit.wikimedia.org/r/1134391

Mentioned in SAL (#wikimedia-operations) [2025-04-07T10:47:35Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1134391|Revert "Take 2: Large math formulae should be scrollable" (T201233)]]

Mentioned in SAL (#wikimedia-operations) [2025-04-07T10:53:02Z] <ladsgroup@deploy1003> jdlrobson, ladsgroup: Backport for [[gerrit:1134391|Revert "Take 2: Large math formulae should be scrollable" (T201233)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-04-07T11:00:47Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1134391|Revert "Take 2: Large math formulae should be scrollable" (T201233)]] (duration: 13m 12s)

I just deployed the revert. Let me know if it's still not fixed.

What is needed to move T201233: Long math output unreadable on small screens due to scrolling off the side of screen forward?
Specifically https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1134297 should lower the risk of the change considerably if we can at least get that one merged soon.

It's not clear to me how tiny, often literally invisible, scrollbars inside each math element address the problem. I imagine quite a lot of users will either never think to, or find themselves physically unable, to slide such a scroll bar.

This works for the page or app as whole, and even for fullscreen elements like a table or image lightbox, but perhaps not for in-line blocks like a math formula?

Why is it that every element that can overflow needs its own dedicated scrollbar solution? This is going to keep coming up for every tag, every extension, every template. Is this something we can address at the skin level instead? On desktop this has generally not been an issue because the page content and browser window were fluid together horizontally, which means the page-level scrollbar is (visibly or invisibly) where users expect it to be, and it naturally controls the content area as well.

On mobile this can presumably work as well, although in Minerva it currently doesn't (the white background stops and the element flows over into the parent container's grey background instead). Likewise Vector 22 current doesn't either. But is this not solvable?

Dedicated optimisations like we do for tables and large images are great, and a net-improvement for UX. For shallow elements like math, the status quo is actually quite good in terms of discovery and accessible (albeit not pretty). A dedicated solution at this small scale, might make the UX worse than the simple page-level scrollbar we have today for overflow.

But can we provide a better default? Especially for inline blocks, there isn't really any alternative anyway since the nearest block would be a paragraph. And yes, we reduce that problem with ever more forceful word breaks but that has no effect beyond text nodes. Once we have that, it naturally handles block-level math as well.

See also: News readers, email clients, issue trackers (ie Phab), readme content (eg GitHub), and anything else that displays free-form web content in (effectively) fullscreen fashion at narrow viewports.

I looked at the code and am a bit worried about the change of the alignment.
I would really like to focus on getting native rendering final instead of testing css hacks. I can deploy it to a test wiki and we can ask the community for review?

In T201233#10787138, @Physikerwelt wrote:

I looked at the code and am a bit worried about the change of the alignment.
I would really like to focus on getting native rendering final instead of testing css hacks. I can deploy it to a test wiki and we can ask the community for review?

I don't understand? What is the change of alignment here? The patch https://gerrit.wikimedia.org/r/c/1134297 should make no difference to current rendering - it just provides a class that will allow us to improve styling on mobile (which can be done outside the Math extension if you are concerned).

Let me know if I can clarify anything here.

Sorry, I didn’t see the additional element in the class name. I’m not at all against the change. However, I would prefer if someone else could review the changes. All math related changes seem to fit best to the math extension. Everyone with global +2 rights can review changes in that extension. Does that sound plausible?

Change #1134297 merged by jenkins-bot:

[mediawiki/extensions/Math@master] Add mwe-math-element-inline class to all Math elements where applicable

https://gerrit.wikimedia.org/r/1134297

Change #1154054 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Math@master] Improve styling of large Math equations on mobile

https://gerrit.wikimedia.org/r/1154054

Change #1134298 abandoned by Jdlrobson:

[mediawiki/extensions/Math@master] Take 3: Large math formulae should be scrollable

Reason:

See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1154054

https://gerrit.wikimedia.org/r/1134298

@Jdlrobson-WMF what is the status of this task? Can we somehow resolve it, or define what exactly who needs to do what?

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1154054 is still awaiting code review and merge. The proposed code has been running on English Wikipedia (https://en.wikipedia.org/wiki/MediaWiki:Minerva.css#L-110) since September so we can be confident it addresses the problem. It would be nice to get it onto other wikis.

I'll do a quick test and merge it.

As noted in my comment this is not a complete solution it just addresses the scroll issue in the most common places on articles. We can expand to other cases at a later date.

To expand:

• it only works on block Math elements (not inline)
• It only applies to mobile and tablet resolutions (e.g. less than 999px;)

Please use the test page https://en.wikipedia.beta.wmflabs.org/w/index.php?title=MathML and be sure to render via Mathoid SVG by default.

On this page after my patch you should have no horizontal scrollbar at resolutions lower than 999px
You should see scrolling on block elements such as these:

Ok, now I was eventually able to reproduce it. While the patch does what it's supposed to, it makes reading on a phone a bit harder, as one has to move the formula independently of the text, and one has to wait very long for the scroll bar that hides the actual formula to disappear.

Change #1154054 merged by jenkins-bot:

[mediawiki/extensions/Math@master] Improve styling of large Math equations on mobile

https://gerrit.wikimedia.org/r/1154054

Thanks for the context and feedback.

I’d like to work on a small follow-up improvement to address the mobile readability concerns mentioned above, if that’s okay.
Please let me know if you have any guidance or preferences before I start. Thanks!

In T201233#11531182, @SheetalPro wrote:

Thanks for the context and feedback.

I’d like to work on a small follow-up improvement to address the mobile readability concerns mentioned above, if that’s okay.

That would be highly appreciated.

Please let me know if you have any guidance or preferences before I start. Thanks!

For me, screenshots help a lot with the review. Maybe it would also be a good idea to file a dedicated task for this.

Problem:
On small screens or narrow browser windows, long MathML expressions do not wrap and extend beyond the visible area, making them difficult to read.

Steps to reproduce:

1. Open https://en.wikipedia.org/wiki/Fibonacci_sequence
2. Scroll to the “Mathematics” section
3. View the long math expressions on a small screen or by narrowing the browser window

Expected result:
Long math expressions should wrap or otherwise adapt to the viewport width so they remain readable without horizontal scrolling.

Actual result:
Math expressions remain on a single line and overflow horizontally, causing readability issues on small screens.

Notes:
This is a follow-up to task T201233, which addressed horizontal scrollbar behavior on desktop. This task focuses specifically on mobile and small-screen readability of MathML content.

I’ve created a dedicated follow-up task for the small-screen MathML wrapping issue and attached screenshots. Linking it here for reference: T414865

I’ve created a dedicated follow-up task focusing on mobile and small-screen MathML readability and attached screenshots. Linking it here for reference: https://phabricator.wikimedia.org/T414866

In T201233#11551573, @Wellverywell wrote:

@Jdlrobson-WMF user @Bezik on Russian Wikipedia has reported that this is actually a breaking change.
In any theme (MinervaNeue, Timeless, Vector-2022), any browser (Firefox, Vivaldi), without user CSS, when increasing browser scale/decreasing window width any punctuation marks after formulas go on the next line. Example on this page:

I've investigated this issue and pinned down that it's due to commit https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1154054. What I think is happening is when window width goes below @max-width-breakpoint-tablet, width: 100% is activated even for .mwe-math-element-inline elements, which makes them non-inline, and the punctuation mark goes off. In my opinion that style should not be applied to .mwe-math-element-inline elements.

I think it would be solved by replacing width: 100% with max-width: 100%.

Switching to max-width would probably work Want to submit a patch and I'll take a look ?

Change #1233112 had a related patch set uploaded (by Escargot bleu; author: Escargot bleu):

[mediawiki/extensions/Math@master] Replace width with max-width in ext.math.less

https://gerrit.wikimedia.org/r/1233112