I can confirm the issue. Initially it seems like everything is working when opening the link but after a few seconds the page reloads multiple times until the error message appears. A similar error message appears when trying to open the link via Chrome on iOS. But I can't reproduce the bug on other pages – I'm wondering if the page size or a certain element on the page is to blame (Safari on MacOS also took longer than expected to load the page).

Tested both links on Chrome browser via Android 10 on a Samsung Galaxy S9 Plus. Haven't encountered the issue, though the page of the primary link pushes down after the loading finishes.

The page directed by the main link now loads well. Perhaps the archiving must've fixed the issue: https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_%28policy%29&diff=1354130069&oldid=1354129855

Maybe I can test the latest diff link on my iPhone Never mind. The mobile web version shows only edit changes.

The other link should do for further testing: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)&oldid=1354129855#Counter-proposal:_Amendments_to_WP:NOCON's_wording

UPDATE: Hmm... Can no longer reproduce the same issue on an iPhone.

I encountered the same issue but with a different Village Pump page: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#Survey

Screenshot:

Happening in not just most recent iOS stable versions but also iOS 16.

Just in case: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(WMF)&oldid=1356083155#Survey

I may like to list plenty of other links of the same page, like the following of the other same link:

• active: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)#Discussion
• revision: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(WMF)&oldid=1356086630#Discussion
• screenshot:
  

That'd be one too many.

I'd have to assume it's something about the highlighting / auto-expansion code that's clashing, presumably in ways that're more noticeable on larger (and thus slower-to-load) pages.

Some debugging:

1. safemode doesn't stop it, so it's not a gadget / site-scripts issue
2. dtenable=0 doesn't stop it, so it's not a discussiontools issue at all (contra my previous comment)
3. useformat=desktop stops it, so it's something in the mobilefrontend stack
4. forcing a different skin via useskin=monobook stops it, so it's something to do with mobilefrontend + minerva

I don't have a USB-C cable to hand. Once I get one, I'll actually connect a phone to a debugging setup and look into it more directly.

Connecting a cable didn't help as much as I had hoped. The main thing learned was that this isn't the page actually being stuck in a reload loop via navigation, but rather the rendering is crashing and restarting. I was also able to place breakpoints in Toggler.js which weren't reached (or at least, the process crashed regardless and things moved on -- hard to tell the difference).

The remote inspection of the iOS system logs via Console.app reveals this error: Process com.apple.WebKit.WebContent [854] killed by jetsam reason per-process-limit which seems to suggest it's hitting a memory limit. So, it seems that what we have is a WebKit issue where something about the MobileFrontend+Minerva arrangement makes navigating to a section via fragment balloon memory-usage.

I suspect the next step to take would be to get a local reproduction of the issue on my dev environment (which I've been avoiding because getting my phone loading that is always a pain) and seeing whether throwing content-visability: auto around might help reduce the initial memory burden.

forcing a different skin via useskin=monobook stops it, so it's something to do with mobilefrontend + minerva

Did you try useformat=mobile&useskin=monobook ? That would help eliminate whether Minerva has anything to do with this.

This could be Parsoid related since all mobile page views go through Parsoid on en.wikipedia.org

Did you try useformat=mobile&useskin=monobook ? That would help eliminate whether Minerva has anything to do with this.

I didn't explicitly do it, but it was on the phone so I wouldn't have thought that useformat=mobile would make a difference? Either way, I just tried it again with the parameter explicitly present, and it does still prevent the issue.

This could be Parsoid related since all mobile page views go through Parsoid on en.wikipedia.org

Good call on that one -- useparsoid=0 also fixes it, when in mobile and minerva.

Does this trigger with using "desktop" mode on iOS Safari, but with useparsoid=1? My assumption is that this is a MobileFrontEnd bug, not necessarily a Parsoid bug.

• Has bug: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)?useformat=desktop&useparsoid=1&useskin=minerva#Survey
• Does not have bug: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)?useformat=desktop&useparsoid=1&useskin=vector2022#Survey

So: not actually a mobilefrontend one technically, but a minerva+parsoid one, I guess?

My skin for the mobile web is Vector 2022, and the mobile web has been crashing under that skin also. What's the URL code for that one?

@gh87 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WMF)?useformat=desktop&useparsoid=1&useskin=vector2022#Survey should get you that. It could be somewhat device-dependent, since the apparent error is RAM-exhaustion -- I'm testing it on an iPhone 17 pro, meaning there's 12GB of RAM.

Might be worth leaving the MinervaNeue tag on, just because it's significantly easier to trigger there, so there may be some relation.

One more reproduction note: I cannot reproduce this when I have JS disabled.

Ok, this makes more sense that a JS interaction would cause memory exhaustion (vs just a particular magic sequence of HTML).

Why MobileFrontend @gh87 ? See @DLynch 's earlier comment. This could be any extension's JS running in the context of Minerva skin and Parsoid HTML but I think we can safely rule out Parsoid and MobileFrontend at this point?

@Jdlrobson-WMF Just trying to find JS-related project tags. Dunno any other. Never intended to reinsert the MobileFrontend tag or add a subproject tag, ya know.

No worries just wanted to make sure I wasn't misunderstanding the discussion so far! Thanks for the clarification.