I guess the culprit is https://issues.chromium.org/issues/391990606. The previous behaviour is a feature commonly called "font boosting".

The state of that ForceOffTextAutosizing flag depends on an ongoing A/B test ("finch experiment" in Chromium people's words; use chrome://version/?show-variations-cmd to see it). It may have been rolled out at the beginning of this month.

I tried disabling chrome://flags#force-off-text-autosizing on my Android phone (Chrome 141.0.7390.111). The behaviour indeed returns to the previous one (some of the text are enlarged).

I would say the main issue is Vector 2022 was not designed with responsiveness in mind, and some people depended on browser fixes to use it on mobile phones. Now Chromium developers plan to remove that fix.

Thanks @Bewfip

I think adding the following to Special:MyPage/common.css is seems to also a good short term solution but with no guarantee that will continue working:

.mw-body-content {
    text-size-adjust: 200%;
}

This also impacts legacy Vector, and Monobook.

just noting that iOS Safari also automatically applies text-size-adjust (you'll note the desktop view fontsize of the content is significantly larger than that of the sidebars with the links, though not as aggressive as Chrome does it). I'm not aware of Apple planning to remove this.

What should have happened instead?:

Can you clarify if you think font boosting is desirable or undesirable? I argue it is undesirable in T407938: Vector 2010 and Vector 2022 pages on mobile have some text randomly too big. Your before and after screenshots imply to me that you might think font boosting is desirable behavior.

In T407447#11300086, @Novem_Linguae wrote:

Can you clarify if you think font boosting is desirable or undesirable?

The "font boosting" behaviour should be desirable when it works, for accessibility reasons. Unfortunately it leads to inconsistent results sometimes, because the algorithm is based on heuristics.

Some materials about this feature can be found at https://developer.mozilla.org/en-US/docs/Web/CSS/text-size-adjust#see_also

Shouldn't we font boost everything then, such as the hyperlinks in the tools menu on the right, and not just article text?

My first preference is to not font boost anything (and if font is too small, the user can use Minerva, switch phone to landscape mode, or pinch zoom).

My second preference would be to font boost everything, so that we don't get mobile screenshots containing a mix of very large and very small text.

I think having a mix of very large and very small text on the same screen looks weird and would seem like a bug to the end user.

Personally I'm fine with increasing the font size of (some of the) content text only, and leave less important sidebars as is. It is "broken", however it has been the default mobile browser behaviour for a decade. Users will likely be familiar with it, unless most of the desktop-only web pages they have seen are from pedantic web designers that surpress this behaviour.

Anyway this behaviour is going away in Chromium, unless they change their plans.

In T407447#11301798, @Novem_Linguae wrote:

Shouldn't we font boost everything then, such as the hyperlinks in the tools menu on the right, and not just article text?

The default text inflation algorithm ( text-size-adjust:auto ) (now the default has apparently been reset by Chrome to none), specifically inflates 'main' content and headings. The idea of mobile device text inflation, was that the main content is the most important content on the page. It is what you want to read easily and what changes per page of your website. Anything else (like sidemenu's, headers and footers) is less important and can be reached with effort (double tap to zoom, or pinch to zoom) for those who need.

Remember, this is not about optimizing your website for mobile, that's what having a responsive skin is for that adapts to limited width.

The feature will be disabled by default in Chromium 143 (https://chromiumdash.appspot.com/commit/b0326c486eede79c80d23b690cd61eceeab159e3).

It probably has already been the case for most Chrome users (under the impact of A/B test). Now it will affect other Chromium-based browsers.

I've left a note on the Chromium issue https://issues.chromium.org/u/1/issues/391990606. just to ensure that they are aware that people are noticing this change quite a bit.

I've left a note on the Chromium issue

@TheDJ / @Bewfip Thanks for the ping, and investigation so far.

This feature has a long and somewhat complex history, but effectively it was reaching a point where it was doing significantly more harm than good.
Web-developers running into this behavior is a frequent source incoming bugs into the Chromium bug tracker. As this "activation" was heuristic based it seemingly applied to "random" elements on their sites, and as such most people viewed this as a browser bug.
Additionally the heuristics depend on other factors such as the size of the device - e.g. people with smaller vs. larger phones may see vastly different rendering causing additional confusion.

Its very uncommon for browsers to change the rendering of a web-page in such a heavy handed manner, this feature was initially developed to bootstrap the mobile web at the time (~2007), and it did so successfully.

Any changes to the heuristics are basically non-viable at this point, e.g. any "fix" that we'd try to apply would risk accidentally enabling this feature on more sites than intended - breaking users.

If Wikimedia wishes to support this use-case (of using the desktop site on mobile, and have text boosted on particular elements) then boosting text manually on paragraph text via text-size-adjust: 200% or similar is the right mitigation - only text-size-adjust: auto is being changed - however ultimately this is your decision if to apply this, and to what elements.

Thanks, Ian

(Additionally there a separate feature to allow detection of the users device text-scale via. env(preferred-text-scale) - https://chromestatus.com/feature/5328467685801984 which helps users who have requested a larger font-size in OS-level settings for the page to respect it).

Hi, this is Philip from the Chrome team. An option is to add text-size-adjust: clamp(100%, calc(100% * env(preferred-text-scale)), 140%); to .mw-body. This line will be ignored on browsers that do not support env(preferred-text-scale), and will cause the OS text scale to be applied to that element on browsers that do support it. The clamping keeps things reined in a bit, similar to the old text autosizer behavior, but is optional. You can test this in chrome with the "Emulate OS text scale" option in devtools + mobile emulation (see screenshot). At least one major site has launched with this approach (Reddit).

Thanks @Progers1618 and @Bfgeek for your input! Much appreciated!