I have no idea why this is happening

It seems you made some changes to the Main page...? It looks like this introduced the issue:
https://en.m.wikipedia.org/w/index.php?title=Special:MobileDiff/1069328725&type=revision&diffmode=source

This has changed the structure of the page as the in-block class is added (and always has been added) to any subheadings. The introduction of an h1 has confused the mobile formatting code.

Out of curiosity why the change? There is already an h1 in the page hidden via CSS.. If you want to add an h1, you might want to consider setting https://en.wikipedia.org/wiki/MediaWiki:Mainpage-title to Welcome to Wikipedia and incorporating the header in the main page styling .mw-first-heading.

Yay, I knew there would be something wrong with that change.

There is already an h1 in the page hidden via CSS

I did this at the request of @stjn since a display: none heading is not read out for accessibility aids (etc. etc.) and not having an h1 is generally bad. This is in duo with the change made on WMF's side to add the message in question. (It was bad before WMF's change too.)

That said, I think MF is wrong here to be adjusting how headings work. What use case is MF trying to fix here?

Added for T106347: Safari regression: Edit button for H2 left aligned in mobile.init.styles.less. Blgh. Does Safari still need that hack?

Alternative other place to change would be SubHeadingTransform.php, which does already have a TODO (though it looks like a TODO of the 'change the name' sort?).

Yeah, if we want to say that <h1 id="firstHeading"> should be the only <h1> on the page, then it should not be hidden completely (but via visually hidden class). Also, since most wikis do not consider this at all, someone would need to get the list of main pages where <h1> is already present. All in all, it seems that easier solutions are either to see that the hack is relevant, as Izno said, or maybe at least remove it where it is irrelevant (such as here, actually: why add in-block class into headings without edit section links?).

It looks like we accidentally fixed the original issue by way of T305971: Change styling for Minerva/MobileFrontend section headings to use flexbox instead of table-cells, so this task may no longer be necessary.

In T300695#7926120, @matmarex wrote:

It looks like we accidentally fixed the original issue by way of T305971: Change styling for Minerva/MobileFrontend section headings to use flexbox instead of table-cells, so this task may no longer be necessary.

I don't think it is necessary, but let me test how the h2s on the main page react with the flex styling. So yes, the original issue is resolved. :) in-block doesn't appear anywhere else in either Minerva or MF besides the PHP class the current task is scoped as.

The task is still valid IMO. We don't use these transform for anything so we should remove the code (more info @ T261805).

Hi @Shresta05 are you working on this task?

Change 851166 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/MobileFrontend@master] Remove SubHeadingTransform and the 'in-block' CSS class

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

I'd like to do this ahead of T13555, so that there is one less thing to update.

Change 851166 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Remove SubHeadingTransform and the 'in-block' CSS class

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

Nothing seems broken to me but I still see the in-block class

However, there's no styling applied as shown below:

@matmarex , any thoughts on this? Looks good to me but I could be missing something.

In T300695#8372465, @EAkinloose wrote:

Nothing seems broken to me but I still see the in-block class

This task is on next week's train.

In T300695#8372471, @Izno wrote:

In T300695#8372465, @EAkinloose wrote:

Nothing seems broken to me but I still see the in-block class

This task is on next week's train.

Makes sense. Thanks for clarifying that.

It works fine on the Beta Cluster. I'll go ahead to close it.