To avoid this, MobileFrontend should "re-duplicate" the styles before doing its thing, and then de-duplicate them again after. As it happens, I implemented exactly this in JavaScript for T287675: reduplicateStyles(), deduplicateStyles(). Someone would just have to port it to PHP, and call it in MobileFormatter::filterContent(). For reference, here's Parsoid's own PHP implementation of de-duplicate: DedupeStyles.php (it doesn't need the re-duplicate operation). Parsoid is now included in MediaWiki, so one could use all of the Wikimedia\Parsoid\… stuff (and one should, it really makes using DOM in PHP bearable).

Of course strong support for fixing this.

I haven't looked into it, but rather than reduplicating then deduplicating again, couldn't the MobileFronted search for the TemplateStyles stuff in the elements it is about to remove, then replace the elements with the found TemplateStyles instead of removing everything?

It could, but it would be trickier to implement. The first problem is that the code that does the removals is actually implemented as a separate library called HtmlFormatter, so you'd have to make changes there, then make a release, then upgrade it in MobileFrontend. (And they might not even want to have that feature in it, as the libraries probably shouldn't have MediaWiki-specific features.) The second problem is that when you do that, it's easy to end up with invalid HTML, e.g. if you remove a table cell that contained styles while keeping the styles, you'll have a <style> tag inside a <tr> tag, which is invalid. (Resolving that is possible, but you need to know which elements can have which children, so it's easier to just rely on Parsoid, which already took care of that.)

Just so it's known, I hack around this slightly in navbox and sidebar currently with move_hiding_templatestyles which hoists the TemplateStyles strip markers outside of the relevant HTML (which was inspired by Module:Infobox doing something similar for the purpose of avoiding hidden rows). It obviously doesn't solve the general problem like occurs with Navbox top where the module can't reach into the content of {{navbox top}} .. content .. {{navbox bottom}}.

hey all, sorry this was the first I've ever heard of this bug.
I'll see what I can do to prioritize it.

On the one hand, MobileFrontend is doing exactly what it should do - using nomobile class should remove everything contained in the element from mobile.
On the other hand TemplateStyles de-duplication code needs to be aware of this or MobileFrontend should be aware of how TemplateStyles de-duplicates styles to make sure this is considered prior to removal.

I'd rather focus on removing the need to strip HTML from MobileFrontend. In production the main reason for this feature's existence is navboxes given it cannot even be rendered correctly on mobile (needs an update to template) and constitutes 1/3 of the HTML payload for many pages.

Personally I think we should stop scrubbing nomobile content from HTML and for now rely on CSS to hide. I think that would mitigate most of the issues here that editors hit. We've been leaning more towards identical parser HTML for mobile and desktop and it's an anti-pattern to serve different content to mobile/desktop users and we only do it as a workaround for the limitations of template markup.

I'm not sure why you singled out nomobile (in code marks). The issue in this task remains with both navbox and vertical-navbox and any other class name we might assign in the relevant configuration.

We've been leaning more towards identical parser HTML for mobile and desktop and it's an anti-pattern to serve different content to mobile/desktop users and we only do it as a workaround for the limitations of template markup.

If this task is enough to overcome the inertia of the "heavyweight" templates that are the predominant reason for T124168 not having been "fixed" yet, I'd be as happy as anyone (well, not really, but not unhappy I guess) (I think specifically navbox being a mess on mobile is something that can inspire editors to action if they actually see it being a mess, so it really does come down to how heavy those templates are when they're used as intended...).