The problem here is that mbox- class is used in other places and last time I checked not very friendly to mobile phones. I don't know how widely used these are on Russian Wikipedia, but wikis should feel free to re-define what content gets stripped via a site configuration change to wgMFRemovableClasses. No changes to MobileFrontend or Minerva are needed here.

If changing the configuration you might want to consider how this looks on a mobile phone and make a few adjustments first? Perhaps these templates could be condensed to a single line with a "show more" link?

In T280593#7022853, @Jdlrobson wrote:

The problem here is that mbox- class is used in other places and last time I checked not very friendly to mobile phones. I don't know how widely used these are on Russian Wikipedia, but wikis should feel free to re-define what content gets stripped via a site configuration change to wgMFRemovableClasses. No changes to MobileFrontend or Minerva are needed here.

First and foremost, these transforms should not apply on elements without a class ambox if their CSS styling is only applying to that class. As seen on [1], this looks broken, so some changes in MobileFrontend or Minerva are obviously needed. Second, were these transforms really intended to apply outside of action=view?

[1]: https://ru.m.wikipedia.org/w/index.php?title=Россия&action=edit

Transforms apply to all pages. We have no concept of page specific transforms at the current time. We have a configuration option MFMobileFormatterOptions so I suppose we could. There are plans to limit transforms on talk pages (T280051) so perhaps that would allow us build on that.

As seen on [1], this looks broken, so some changes in MobileFrontend or Minerva are obviously needed.

https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L17223 is what's causing this.

MobileFrontend is behaving as expected.

Adding the following would fix that:

'ruwiki' => [
		'base' => [
			'.navbox',
			'.nomobile',
			'.vertical-navbox'
		],
	],

In T280593#7025832, @Jdlrobson wrote:

MobileFrontend is behaving as expected.

Maybe I explained myself wrong, but the issue at hand is not the fact that MobileFrontend ignores .mbox-image, that is OK, the issue is it applying transforms for .ambox class 1) on the page view where it doesn’t make much sense to, 2) without the accompanying CSS. So, this .fmbox (hence why I wrote mbox-class templates) has a hanging ‘Learn more’ for no reason, and IMO it shouldn’t even be affected by these changes to move article notices into ‘Page issues’ popup.

I believe that issue is separate and already tracked in T215271

In T280593#7026139, @Jdlrobson wrote:

I believe that issue is separate and already tracked in T215271

That task is, again, about mbox-image and not what I am talking about here. Do you see ‘Узнать больше’ on my screenshot above? (Russian for ‘Learn more’.) It is showing up unstyled in a message box with the class .fmbox because of CSS issues in MobileFrontend (it targetting .ambox class) and does not hide anything. I do not care about the mbox-image not showing up, I filed this because an unstyled button should not show up there. I don’t know how else to explain this, and will probably close the task myself if this attempt is unsuccessful, too.

Okay I understand. Yes and I assure that is tracked in T215271. "".fmbox" are treated like page issues" and should not be treated like page issues. Quoting from the comments there ".fmbox shouldn't be treated like a page issue because the class is not used for page issues - it is used for edit notices and system messages "