This is a great idea and would make the "random page" feature *much* more useful. Hopefully it doesn't prove to be too difficult to implement.

@Dragoniez my zoom level is 100% with a viewport width of 1280 pixels (window.innerWidth). But zooming out to 90%, resulting in the width being 1422 pixels, removes the scrollbar.

@cscott would it be possible to have two functions, which can be used depending on whether one wishes for the normalization step?

@TJones Thanks for the writeup. So it seems like the paradoxical situation arises because, in response to ſ, the normalizer tries S before s. Given that ſ is always s and never S in actual usage, this seems suboptimal, so I support the early normalization idea. But I am really surprised that all of your benchmarks showed string operations taking at least a full microsecond (an eon by modern CPU standards), including when nothing is changed at all! Is it possible that the actual performance killer is just PHP overhead? It seems like PHP supports FFI, though I doubt it will come to that.

This is a disappointing response. A horizontal scrollbar does not equal "broken". Content being cut off is absolutely, unambiguously, broken. Moreover, a horizontal scrollbar on the entire page has the advantage of allowing a mobile user to zoom out the viewport and get a better view of the wide content, and a horizontal scrollbar on an individual element doesn't.

Noting that this has also broken Wikipedia articles with wide equations, e.g. https://en.m.wikipedia.org/wiki/Trace_(linear_algebra)

I got this error on a couple of pages just now, not sure if it's related to this.

Fixed.

This bug is still present as of 2025, but I see that this report hasn't even been triaged. Is there any reason for that?

I added some instrumentation an hour ago: https://en.m.wiktionary.org/w/index.php?title=MediaWiki:Mobile.js&diff=prev&oldid=83679756 and it seems this bug only impacted less than 100 page views in the last hour, so I don't think this is something we need to seriously worry about. I can leave the instrumentation running a bit longer to get a sense of daily impact if that helps reassure you.

Update: looks like frwikt, the second largest Wiktionary, has deployed an adapted version of the gadget (https://fr.wiktionary.org/wiki/MediaWiki:Gadget-wikt.page-preview.js) which is pretty cool.

The user experience on mobile is once again rough.

@Jdlrobson could you please retry the night mode check with the AutoContrastFixer gadget enabled? As explained in the issue description it is necessary to automatically fix contrast issues until all of our templates are updated.

All done.

@Pppery Thanks for letting me know. In that case I'm going to assign it to myself :D

This seems to still be occurring on certain pages like Special:Log.

@SToyofuku-WMF Looks to be working now! I've created a task to enable dark mode for logged-out users: T381058

Doesn't seem to be live on enwikt — do I need to clear my cache?

@Jdlrobson — actually, after doing some more digging I think this involves adding the mobile-anon-talk flag to the wiki. But I'm not sure whether that does the same thing as what you proposed.

I noticed that jQuery (300 KB) is still getting loaded unconditionally. What if we had it off *by default* (i.e. in safemode) and only loaded it when someone uses a script that has it as a dependency?

@Formatierer: Just letting you know that I have documented this bug/feature here: https://www.mediawiki.org/w/index.php?title=Manual:PAGENAMEE_encoding&diff=prev&oldid=6798438. Fixing it now after almost a year would probably break some system relying on the *new* behaviour, and it doesn't even look like any progress is being made. In my opinion, you might as well just mark this as resolved if my documentation looks okay.

@Jdlrobson here's how it looks on Wikipedia on (Chrome 129.0.6668.100):

I think @Surjection is being too pessimistic. Mobile has been problematic in various ways for a while so it's understandable that a slightly suboptimal setting has flown under the radar. However, it seems a little silly to be so worried about reflows when the site already has popups and banners that are *much* more disruptive than what's being proposed. Also, it doesn't matter how long T374883 takes because I *oppose* applying it on the basis that it precludes any Wiktionary specific logic that we could apply through JavaScript. For example, on an entry with a large English section and a couple small sections in other languages (e.g. https://en.m.wiktionary.org/wiki/coke) it seems like a no-brainer to have English expanded. But on an entry like https://en.m.wiktionary.org/wiki/bulan it seems more reasonable to have everything collapsed and to show the miniTOC instead. This can be hashed out on-wiki. My suggestion to the developers is: if reflow is a concern, allow us to control collapsing behavior on the server side — maybe a special keyword like _COLLAPSED_ in the wikitext. Then a template can be added with whatever custom logic is necessary.

I agree that some hacky JS isn't ideal because users would see a flash of the collapsed headers until that code runs. If there's a reasonable ETA for @Jdlrobson's idea then we could wait for that. But as I wrote in the on-wiki discussion there's value to have a system managed by the community which can be customized as necessary (e.g. always expand English and Translingual, or go by section size, etc etc).

In T376363#10199055, @Aklapper wrote:

Could you elaborate why you think that there is any wrong behavior currently? The default existing tabs also get "unstyled" when removing the minerva__tab-text class. I don't see any bug.

@Jdlrobson thank you for clearing that up. My issue, which referenced Minerva specifically, was closed as a duplicate of this one which I guess must have been a mistake. Thank you for the patch!

In T375876#10186135, @Jdlrobson wrote:

It only got reported now. I think this is a pre-existing bug that nobody noticed. Here's the bug on a patchdemo instance from August: https://patchdemo-legacy.wmcloud.org/wikis/23aae23bdc/wiki/Self_link

@jhsoby the patch you linked is from June — how could it be only taking effect now?

Add to your CSS:

Using JavaScript for this in MediaWiki core makes no sense because this is completely static content (on Wiktionary it's implemented this way purely by necessity). Also, it doesn't seem like it checks whether or not the link is a redlink. If I were implementing this as a gadget, I would put all of the links into the Parse API and use that (so one API call per page — not too bad) to guarantee that the HTML is exactly the same as it would be on a regular page.

Not sure if this is the right place for this but I was referred to this task by @Izno. Is it possible to locally disable all the overrides containing the hacky selector [style*="background"]? To be clear, I want things as broken as possible to make it easy to identify which templates need to be updated.

We were able to work around this issue using some JavaScript (diff), so I think this task is no longer necessary.

I agree with stjn above. This is the only reasonable solution.

@ovasileva @Jdlrobson: This has been resolved on the English Wiktionary with the introduction of a new gadget (https://en.wiktionary.org/wiki/MediaWiki:Gadget-PagePreviews.js) capable of previewing a wide range of links. Perhaps the code can be reused on other projects. By the way, your acceptance criteria are not very well thought-out in my opinion.

@stjn this appears to still be a problem as seen at https://en.m.wiktionary.org/wiki/water. I was able to fix it by applying the style

.mw-heading * {
	word-break: normal;
}

The same issue exists on the English Wiktionary mobile site as seen here. The button is supposed to say "Look up".

@Jdlrobson it has been over a year, has there been any progress made on this issue?

I think this could resolve this - https://gerrit.wikimedia.org/r/c/css-sanitizer/+/1052146

@Ebrahim Could you look into this?

In T349908#9932645, @Jdlrobson wrote:

In T349908#9932591, @Ioaxxere wrote:

@Jdlrobson why was this removed? It's very unintuitive that Mediawiki:Mobile.js works as expected but not this. As a stopgap (that also works with CSS) I've noticed that body.mw-mf only exists on the mobile site.

High level summary: MediaWiki:Mobile.js was always temporary and primarily developed for Wikimedia sites (on 3rd parties it doesn't work at all). We are working with communities to remove it and apply MediaWiki:Common.js to the mobile site so Minerva works consistently with other skins.

More details in T248416#9678769

@Jdlrobson why was this removed? It's very unintuitive that Mediawiki:Mobile.js works as expected but not this. As a stopgap (that also works with CSS) I've noticed that body.mw-mf only exists on the mobile site.

In T31118#9042921, @cscott wrote:

There's a long discussion in the parent task, T25932, summarized by "wikitext is not a superset of HTML". If we want to allow markup like:

<details open>
<summary>(short description)</summary>
;Name
:Lorem Ipsum
</details>

then the best way forward (in terms of future maintainability) is not to "just" allow arbitrary use of <details> and <summary> tags in wikitext, but instead to start by adding a new parser function, say {{#details|short description|content}} which will emit the structure that you want. (The 'content' block is a good use of heredoc arguments, T114432.) That is "more semantic" in tat the wikitext author is writing a semantic description of the details box (or whatever), and it allows us the ability to change the exact markup emitted for that parser function in the future. We're not committed to emitting exactly those particular HTML tags in that particular tree structure for all time.

Why can't the entire text be rendered at load time? As long as the browser doesn't run out of memory and crash, it should work fine. I would personally find infinite scroll annoying if for example I were reading Wikisource on an unstable connection.