If this only happens on mobile then this might be in the MobileFrontend extension itself instead of MediaWiki (or maybe maybe in the MinervaNeue skin).

This diff also has the issue meaning the issue is likely caused by the number of files or the size of the file links.

It's not just Minerva, the dropdown icon doesn't show when Vector is set as the mobile skin as well, so it's a MobileFrontend issue.

MobileFrontend sets MFMobileFormatterOptions.maxImages to 1000, and since there's over 1000 images the mobile formatting is not being applied.

In T248796#6013079, @BrandonXLF wrote:

MobileFrontend sets MFMobileFormatterOptions.maxImages to 1000, and since there's over 1000 images the mobile formatting is not being applied.

@Jdlrobson wrote the patch that introduced the maxImages and maxHeadings settings and how they're applied (see I877473bbeb8410f4959553076a78f7c51e4b473e) so his input and any context he can give us would be welcome.

However, it seems to me that those settings should only apply to their respective transforms rather than to all transforms, i.e.

public static function canApply( $text, $options, $transformName ) {
  switch ( $transformName ) {
    case 'HEADINGS':
      return preg_match_all( '/<[hH][1-6]/', $text ) < $options['maxHeadings'];
    case 'IMAGES':
      return preg_match_all( '/<img/', $text ) < $options['maxImages'];
    default:
      return true;
  }
}

For example, I would hope that the MobileFormatter::makeSections transform would run for a page has 1000+ images but only 6 sections.

Consider also https://en.m.wikipedia.org/wiki/Timeline_of_national_flags

The MobileFormatter cannot handle large pages with lots of DOM nodes. That's why this restriction is in place. The problem is the code that parses the code into a DOM. If we can't do that we can't run any transformations including images or headings.

My suggestion for now would be to give feedback in the editor via a warning message that the page is too complex for mobile formatting.

(We can also try upping those values as they were set arbitrarily based on articles which were experiencing timeout values. I believe @nray did that analysis.)

At what level is the transformation done? If the large page were broken up into sufficiently small subpages which were then transcluded into a composite top-level page, would that solve the problem?

@RoySmith it's done on the entire finished page so transclusions wouldn't help here. Sorry to not bne able to provide any quick fixes for now :( If you are looking for a short term fix using flag emojis rather than images should help. https://flagpedia.net/emoji

Interesting thought, thanks. I'll suggest it to the OP.

It turns out the OP is having problems accessing phab, but they implemented something very similar and that did indeed resolve the issue.

Change 671000 had a related patch set uploaded (by BrandonXLF; owner: BrandonXLF):
[mediawiki/extensions/MobileFrontend@master] Add comment when MobileFormatter can't be applied

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

@RoySmith would an HTML comment that doesnt show up in the editor be sufficient here?

@BrandonXLF perhaps a <div class="error"></div> is best here as this can be considered a parsing errors like the ones we're discussing in T280766

@Jdlrobson I'm sorry, I didn't realize this was waiting on me for a response. I'm not entirely sure what to tell you. My involvement here was mostly noticing somebody else describing the problem on Village Pump and doing some initial troubleshooting.

As I understand it, this is a "page is too complex" limitation in the MobileFrontend extension which is going to be difficult or impossible to fix, so what we're talking about is how best to communicate that to the user. And the fix suggested in change 671000 is to add an HTML comment which includes the error message.

To be honest, I don't think that's going to be terribly useful. I'm sure somebody like the person who originally reported this on Village Pump would never see that. I doubt I would have seen it either (I'm a software engineer who knows enough to poke around in a browser console but is unfamiliar with the MediaWiki codebase). There's a ton of HTML on a typical wiki page. The odds that I would notice an embedded comment are slim to none.

But, here's a thought; had there been something in the javascript console log, I probably would have noticed it. So maybe instead of (or perhaps in addition to) an embedded HTML comment, a bit of embedded javascript which logs the error to the console? The volume of stuff in a typical console log is quite limited, so it would be much more likely to be noticed there.

I'm not sure how

My suggestion for now would be to give feedback in the editor via a warning message that the page is too complex for mobile formatting.

would look to the editor, but it sounds like a good plan in general.

I hope that addresses your question.

If I or some other person were interested in finding pages with this issue, either to simplify them or to quantify their prevalence, how might that might be done? Is there any global view of the issue? The patch mentioned above (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/671000/) just places an (perhaps not very obvious) indication on the page. Could pages with this issue (when MobileFormatter can't be applied) be added to a list in Special:SpecialPages or be made publicly searchable?

In T248796#7397272, @Anon423 wrote:

Could pages with this issue (when MobileFormatter can't be applied) be added to a list in Special:SpecialPages or be made publicly searchable?

That doesn't seem to be possible, since it's decided based on the HTML of the rendered page, when it's serving it to users, and not when the page is being parsed. At this stage, it can't write to database (for performance reasons).

It would be different if MobileFrontend would store a page property for this at parsing time. I don't know why it wasn't done at this stage, since the recommendation at T232690#5486265 was to use ParserOutput to avoid a preg_match_all. Of course, that would require expensive pages to be parsed again to store those properties on the database.

A conversation on the enwiki village pump (technical) is ongoing, and I'd like to relay a suggestion made there: If possible, pages with this problem could be automatically placed in a tracking category. This would be an item at Special:TrackingCategories, and is apparently the typical way to keep tabs on such issues. I apologize if this is technically difficult.

Yeh a tracking category is not currently possible as this runs /after/ parsing has occurred.

One thing we could do is log an error that could be seen in logstash, but given most editors don't have access to that, someone would need to find a way to relay that information to bots and/or relevant communities.

That said, the logic here is really simple.

https://gerrit.wikimedia.org/g/mediawiki/extensions/MobileFrontend/+/5a3058552ed43521df448f2edf6653bbe6eb7b0d/includes/MobileFormatter.php#95
https://gerrit.wikimedia.org/g/mediawiki/extensions/MobileFrontend/+/5a3058552ed43521df448f2edf6653bbe6eb7b0d/extension.json#788

It happens when an article has more than 1000 images and/or 4000 headings.
Is there a way this can be detected on edit?

A gadget could be crafted that added the category automatically like so:

if(
  ( $('.mw-body-content img').length> 1000 || 
  $('.mw-body-content').find('h1,h2,h3,h4,h5').length > 4000  ) &&
mw.config.get('wgCategories',[]).indexOf('Category:Not compatible with MobileFormatter') === -1 ) {
  
 alert('This page will not work on T248796. Auto-adding category');
// @todo: add category to page.
}

I have added a "compensation" for mobile users into enwiki [[List of works by Vincent van Gogh]]: a multiple image is added to allow the mobile user, reading without TOC, at least to jump to the different lists.

I wasn't aware of the fact that mobile formatter was disabled for large pages before I saw @Ruedi33a's report. It seemed very sad that it's disabled for exactly the pages that need it most.

So I had a look, and it turns out that the performance problem was easy to fix: see details in T317070: MobileFormatter has quadratic performance. If those changes are approved, then the formatter will just work on all pages, and this becomes a moot point!

Change #671000 abandoned by Jdlrobson:

[mediawiki/extensions/MobileFrontend@master] Add comment when MobileFormatter can't be applied

Reason:

Hello this is an automated message.
I am abandoning this patch as it over a year old, and is not currently in a mergeable state. This has nothing to do with the quality of the patch.

If you still care about this patch, please feel free to restore it and rebase it, and we can happily continue the conversation to help you get it merged.

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