So, since this has been sitting here for a while...

Any chance this change could just straight-up be reverted for now until another fix has been determined?

I've explained above why a revert is not possible. We make one group of users happy while making another set of users (tablet users) unhappy. iPad using Vector accounts for more users than mobile devices using Vector. (Still working on finding that silver bullet)

Can't it be reverted at least when the responsive mode is turned off in Preferences? This has severely affected my productivity.

I tried $('meta[name="viewport"]').prop('content', 'initial-scale=0.1'); and it at least saves me the trouble of manually zooming out but I still have to wait a second till I get the full picture.

I think the current possible options are:

• Use user-scalable=yes without the initial scale. (might not work)
• Use JavaScript to enable zooming on iPad (might not work)a
• Revert all, and hide table of contents on mobile devices (https://gerrit.wikimedia.org/r/c/820379) - rather avoid if possible

For each of the options we need to test in iPad, iPhone and Samsung and work out which is the best solution

This is on my TODO list, and I'm hoping to get a patch up by the end of this week so we can get a fix out for next week, but we're a little understaffed right now so it's going a bit slower than I would have liked. Thanks for the patience!

Hi, just adding my voice of frustration to those above. This has been causing major issues for me as a regular Wikipedia editor on mobile for the past two weeks and I finally got around to tracking down what's going on today.

It's not acceptable to say "a revert is not possible"... a change has been made to the prior long-term status quo, which has broken the rendering on mobile. This is a straightforward introduction of a bug that didn't exist before. It will be great if you can find the patch to satisfy the original issue reported above, but in the mean time an immediate revert is essential as this is causing major issues, likely not just for those reporting here, but for all other Wikipedia editors who won't be aware of why this has happened.

Did you read my most recent message?

Yes, I did and thank you for coming up with ideas for a solution - as I said above, the goal of satisfying the iPad issue while also keeping the mobile view correct is of course the best one, and I also thank you and the developers for your hard work on the Wikimedia software, in general it is fantastic for us as editors and readers.

I guess in this instance I'm just confused as to why this hasn't been rolled back in the interim, pending the fix you mention, given the ongoing problems this is causing for multiple users as detailed here and on-wiki. I work in the IT industry, and if we deployed a change which it was later determined had broken something, our policy is to immediately roll back to the prior version. I get that there have been various iterations of this over the past few months, with viewports and without, but the specific commit at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/815765/3/includes/skins/Skin.php#317 seems to be the one causing all the issues mentioned in this thread, and could surely be rolled back forthwith as requested now by Steel1943, Nardog and myself. The commit even removed an existing comment message saying "Make sure the skin is zoomed out on a mobile device; Do not set initial-scale and let mobile device optimize" which is what should have remained....

I think this explains why width=1000, initial-scale=1 do not work well together either: https://www.quirksmode.org/mobile/metaviewport/#link17

I highly doubt user-scalable=yes is the issue (but we should test). That should be the default always and setting it to no is even explicitly discouraged and in some browsers not even allowed. I was thinking however that this font-size zoom-level bug we are seeing might be related to -webkit-text-size-adjust aka text inflation ??? I can imagine that is impacted by zoom levels and viewport settings. "Mobile Safari automatically scales text if it thinks the text will render too small" Maybe we should try testing that with none.

We really need to build some demo html pages that we can then test on multiple devices.

In T311795#8142435, @Amakuru wrote:

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/815765/3/includes/skins/Skin.php#317 seems to be the one causing all the issues mentioned in this thread, and could surely be rolled back forthwith as requested now by Steel1943, Nardog and myself.

Because that change fixes the issue that this ticket was originally about, and we consider that problem to be worse than what you are experiencing. And while that might not matter to you, it matters to other people.

@TheDJ I'll put up some demo URLs by end of the day.

https://stackoverflow.com/a/64998974
This stack overflow also indicates a problem using zoom CSS statements because of text inflation on iPadOS. @Jdlrobson I'll have access to my iPad end of day, so can do some testing.

Change 822132 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] [option 1] drop initial scale, add user scalable

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

Change 822137 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] [donotmerge] [legacy Vector] experiment with disabling text size inflation

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

I've setup the following test URLs for all the different options (test both Vector and legacy Vector):

1. https://patchdemo.wmflabs.org/wikis/223e271d46/wiki/Banana?useskin=vector and https://patchdemo.wmflabs.org/wikis/223e271d46/wiki/Banana?useskin=vector-2022
2. https://patchdemo.wmflabs.org/wikis/0f46c88954/wiki/Banana and https://patchdemo.wmflabs.org/wikis/0f46c88954/wiki/Banana?useskin=vector-2022
3. https://patchdemo.wmflabs.org/wikis/c10b280124/wiki/Banana and https://patchdemo.wmflabs.org/wikis/c10b280124/wiki/Banana?useskin=vector-2022
4. https://patchdemo.wmflabs.org/wikis/6596dd7846/wiki/Banana and https://patchdemo.wmflabs.org/wikis/6596dd7846/wiki/Banana?useskin=vector-2022
5. https://patchdemo.wmflabs.org/wikis/4dfeb420e2/wiki/Banana and https://patchdemo.wmflabs.org/wikis/4dfeb420e2/wiki/Banana?useskin=vector-2022

In T311795#8142444, @TheDJ wrote:

I think this explains why width=1000, initial-scale=1 do not work well together either: https://www.quirksmode.org/mobile/metaviewport/#link17

I highly doubt user-scalable=yes is the issue (but we should test).

Can confirm. Has no effect.

Testing above none of them are ideal. I think 2 is worth iterating on. Will continue.
Samsung Galaxy: 2+3 are the only ones that exhibit correct behaviour. In Vector 2022, the table of contents is unexpectedly collapsed in 3.
iPad: Only 3 and 4 allow zooming, but 4 zooms the UI as well as the text.
iPhone: 2 and 3 (but table of contents collapsed unexpectedly on Vector 2022 in 3, 2 better)

None of that seems to fix it indeed.

Viewport size wise this is sort of logical.. we are defining a viewport of 1000px. That will always be wider than the devices' screens.
An undefined viewport size shrinks pages to fit to an imaginative size (980 on an iPad).
Initial scale 1 causes a 1 to 1 match to device pixels (so stuff falls off the edge on the iphone with width=1000)

The logical method would be to set body { min-width:1000px } or something.... But then we don't have more narrow screens on desktop any longer...
Really we are asking the browser to do something that it apparently cannot do... prepend that the undefined size is bigger than required to fit the contents of the website to the viewport....

@Jdlrobson should really add &mobileaction=toggle_view_desktop to those testlinks btw. It accidentally switched me to mobile initially

Apart from the initial zooming and tiny search bar problem, we who are using the SVGedit tool are also affected by a third problem, namely the edit button when on SVG file pages, such as File:Test.svg is displayed incorrectly. An empty dropdown is shown eventhough the button hasn't been activated which should trigger the dropdown.

Change 822316 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] [donotmerge] Use maximum scale rather than initial scale

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

Change 822316 abandoned by Jdlrobson:

[mediawiki/core@master] [donotmerge] Use maximum scale rather than initial scale

Reason:

Rejected: Zooming is not possible on iPad with this solution.

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

Change 820379 abandoned by Jdlrobson:

[mediawiki/core@master] [Option 3] Revert opinionated viewport for non-responsive skins

Reason:

Rejected: This makes skins display as tablet devices (e.g. no table of contents on modern Vector)

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

Change 822137 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] [donotmerge] [legacy Vector] experiment with disabling text size inflation

Reason:

Rejected: Does nothing

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

Change 822132 abandoned by Jdlrobson:

[mediawiki/core@master] [option 1] drop initial scale, add user scalable

Reason:

Rejected: Does nothing

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

Change 822328 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] [option 2] No initial scale with JS

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

So it seems like the initial-scale is problematic in mobile devices, so needs to go. That begs the question, how do we restore zooming in iPad. The best fix here seems to be to set the zoom in iPad via JavaScript. That's what this patch does. There's an open question around whether we should use user agent to restrict this solution to Safari browser (iPad doesn't have its own user agent) and whether the JS snippet belongs in core or Vector (I'm open to both).
The downside of this approach is there is a flash as it adjusts, which makes me lean towards limiting this to Safari (although perhaps the JS can be tweaked a little more - the zoom calculation value perhaps needs to be clamped).

@TheDJ can I rope you in for some more testing? The proposed patch is now staged here:
https://patchdemo.wmflabs.org/wikis/f641af26db/w/index.php?title=Dog&mobileaction=toggle_view_desktop&useformat=desktop&useskin=vector-2022

Here's another demo where we use a zoom value of 1.001 which also works:
https://patchdemo.wmflabs.org/wikis/7aafa30b74/w/index.php?title=Elephant&useskin=vector-2022&mobileaction=toggle_view_desktop

Hey @TheDJ any chance you could take a look at the patchdemo / patch (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/822328) on your iPad? I think this solution is probably the best compromise. I can backport it this week if we miss the train later today.

@Jdlrobson I'm sorry I missed the earlier ping. I'll check tonight

https://patchdemo.wmflabs.org/wikis/f641af26db/w/index.php?title=Dog&mobileaction=toggle_view_desktop&useformat=desktop&useskin=vector-2022

This seems to work for me.

https://patchdemo.wmflabs.org/wikis/7aafa30b74/w/index.php?title=Elephant&useskin=vector-2022&mobileaction=toggle_view_desktop

This mostly works, but seems to sometimes still fail on iPhone, and zoom out.

The only concern I might have with this solution, is if this does things to the SEO score with Google because of layout instability.... but those are probably measure more at the phone sizes, so perhaps not.

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/b18775537a/w

Okay I've reverted to the better patchdemo and made a few tweaks. Latest patch demo showcases functionality: https://patchdemo.wmflabs.org/wikis/b18775537a/w/index.php?title=Elephant&useskin=vector-2022&mobileaction=toggle_view_desktop @Jdrewniak passing this to you for review now. Please make sure to check zoom on iPad as part of testing.

The only concern I might have with this solution, is if this does things to the SEO score with Google because of layout instability.... but those are probably measure more at the phone sizes, so perhaps not.

My understanding of this is it won't impact SEO because we have a dedicated mobile site, so am not too worried about this. Fingers crossed.

Okay I've reverted to the better patchdemo and made a few tweaks. Latest patch demo showcases functionality: https://patchdemo.wmflabs.org/wikis/b18775537a/w/index.php?title=Elephant&useskin=vector-2022&mobileaction=toggle_view_desktop @Jdrewniak passing this to you for review now. Please make sure to check zoom on iPad as part of testing.

When clicking that link on my 12" iPad Pro, the page contains the following relevant meta-tag:

<meta name="viewport" content="width=1000,initial-scale=1.3673673673673674">

which seems to be in line with the patch. The text seems large, but I can zoom in and out using the native text zoom dialog.

Interestingly, when clicking the "Mobile view" link, (which switches to MobileFrontend+Vector 2022) contains the following viewport tag,

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes, minimum-scale=0.25, maximum-scale=5.0">

In mobile view, wgVectorResponsive is enabled so the skin becomes fully responsive. There's no problems with that mode, but given the community sensitivity to any changes in viewport. The text will be large in desktop without that, but as long as zooming in/out is possible that's what we want.

If you can merge https://gerrit.wikimedia.org/r/c/822328 I can backport it either today or tomorrow.

Change 822328 merged by jenkins-bot:

[mediawiki/core@master] Set initial-zoom via JavaScript to avoid font-scaling issue in iPad

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

Change 824433 had a related patch set uploaded (by Jdrewniak; author: Jdlrobson):

[mediawiki/core@wmf/1.39.0-wmf.25] Set initial-zoom via JavaScript to avoid font-scaling issue in iPad

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

Change 824433 merged by jenkins-bot:

[mediawiki/core@wmf/1.39.0-wmf.25] Set initial-zoom via JavaScript to avoid font-scaling issue in iPad

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

Mentioned in SAL (#wikimedia-operations) [2022-08-18T21:09:51Z] <brennen@deploy1002> Started scap: [[gerrit:824433|Set initial-zoom via JavaScript to avoid font-scaling issue in iPad (T311795)]]

Mentioned in SAL (#wikimedia-operations) [2022-08-18T21:20:07Z] <brennen@deploy1002> Finished scap: [[gerrit:824433|Set initial-zoom via JavaScript to avoid font-scaling issue in iPad (T311795)]] (duration: 10m 16s)

Test wiki created on Patch demo by FloweyTf using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/1c79cf58d0/w

The latest patch demo does not resolve the issue, at least on my end. Device info here: T313123.

In T311795#8144017, @Jonteemil wrote:

Apart from the initial zooming and tiny search bar problem, we who are using the SVGedit tool are also affected by a third problem, namely the edit button when on SVG file pages, such as File:Test.svg is displayed incorrectly. An empty dropdown is shown eventhough the button hasn't been activated which should trigger the dropdown.

Perfect, the zooming and search bar is now back to normal. This third problem is however still ongoing so the task shouldn't be closed yet. To test you can activate the tool and then visit an SVG file.

Confirmed that the patch demo fixes the zooming on my phone when I force the desktop version. It’s back to being properly zoomed out.

Today's backport may have caused a bug. T315620

In T311795#8165543, @gerritbot wrote:

Change 822328 merged by jenkins-bot:

[mediawiki/core@master] Set initial-zoom via JavaScript to avoid font-scaling issue in iPad

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

I reverted this because it caused T315620: Going to an #Anchor link, viewport jumps back to top of page (all wikis, all skins).

...And with the reversal of the reversal, the zooming issue is back...

In T311795#8143743, @Jdlrobson wrote:

I've setup the following test URLs for all the different options (test both Vector and legacy Vector):

1. https://patchdemo.wmflabs.org/wikis/223e271d46/wiki/Banana?useskin=vector and https://patchdemo.wmflabs.org/wikis/223e271d46/wiki/Banana?useskin=vector-2022
2. https://patchdemo.wmflabs.org/wikis/0f46c88954/wiki/Banana and https://patchdemo.wmflabs.org/wikis/0f46c88954/wiki/Banana?useskin=vector-2022
3. https://patchdemo.wmflabs.org/wikis/c10b280124/wiki/Banana and https://patchdemo.wmflabs.org/wikis/c10b280124/wiki/Banana?useskin=vector-2022
4. https://patchdemo.wmflabs.org/wikis/6596dd7846/wiki/Banana and https://patchdemo.wmflabs.org/wikis/6596dd7846/wiki/Banana?useskin=vector-2022
5. https://patchdemo.wmflabs.org/wikis/4dfeb420e2/wiki/Banana and https://patchdemo.wmflabs.org/wikis/4dfeb420e2/wiki/Banana?useskin=vector-2022

Both links on 3 and 4 work on my end while the others don't.

Change 824437 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Set initial-zoom via JavaScript to avoid font-scaling issue in iPad (take 2)

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

Requesting another review from Jan for the 2nd attempt. Important to get this fixed this week.

Text scaling now works in the latest patch demo.

Change 824437 merged by jenkins-bot:

[mediawiki/core@master] Set initial-zoom via JavaScript to avoid font-scaling issue in iPad (take 2)

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

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: iOS 15.5
Browser: Chrome
Device: MBP
Emulated Device:iPad 9

Test Artifact(s):

QA Steps

Load the site in an iPad
Using the font-size toggle (
✅ AC1: The font-size should scale.

Looks like the zooming issues have been fixed!

This dropdown problem on SVG file pages is still flawed however when you're using the SVGedit tool. Attaching screenshot.

This is an unrelated issue with this gadget. Please report on the gadget talk page.

@Jdlrobson But the problem arose along with the zooming and search bar issues, so it is very related indeed. Unless there was some very unlikely coincidence that the SVG edit button problem and the search bar/zooming problem arose at the exact same time independently of each other.

@Jonteemil I think I get what @Jdlrobson is meaning by their comment: The interface functionality of the Wikimedia sites as a whole is their responsibility, but how gadgets respond to changes in the interface (and updating the gadgets) is the responsibility of the community and the editors maintaining the respective gadget(s). The gadget would need to be updated to accommodate whatever changes have been made to the interface ... and in this case, it seems that something definitely changed with the interface to where it affected the gadget.

I'd recommend leaving a message on the talk page of the gadget and pointing them here to see if this is what caused the gadget to not function correctly anymore so maintainers of the gadget can change what needs to be changed.

@Jonteemil: User scripts, gadgets, templates, custom CSS are local on-wiki content. Local content is managed independently on each wiki, by each wiki community themselves. This gadget problem needs fixing on the local wiki.

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/d8fc4fb470/w/

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/b18775537a/w/

Test wiki on Patch demo by FloweyTf using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/1c79cf58d0/w/