Page MenuHomePhabricator

[Bug] Safari doesn't allow font-size scaling on iPad for users viewing legacy and modern Vector
Open, MediumPublicBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

  • Load the site in an iPad
  • Using the font-size toggle (
    Screen Shot 2022-06-30 at 4.21.26 PM.png (50×60 px, 3 KB)
    ) Set font-size to 300%

What happens?:

image.png (1×2 px, 1 MB)

What should have happened instead?:

The font-size should scale.

Developer notes

Adding initial-scale=1.0 to the viewport definition may fix this. Please test.

On browserstack

Can be replicated in:

  • iPad 9th 15
  • iPad Pro 12.9 2021 14

Cannot be replicated in:

  • iPad Mini 2021

Event Timeline

Jdlrobson renamed this task from Allow font-size scaling on iPad for users viewing legacy and modern Vector to [Bug] Safari doesn't allow font-size scaling on iPad for users viewing legacy and modern Vector.Jun 30 2022, 11:25 PM

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

[mediawiki/core@master] Allow font-size adjustment on iOS devices

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

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

I can confirm @TheDJ 's suggested fix works well here.

Change 815765 merged by jenkins-bot:

[mediawiki/core@master] Allow font-size adjustment on iOS devices

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

Seems this too is causing problems: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Search_box_and_default_zoom_messed_up_while_using_desktop_on_mobile

Makes me think that maybe we are better off simply removing the viewport definition again, because mobile browsers don't seem to be made to handle viewport definitions for things NOT mobile, very well.

Seems this too is causing problems: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Search_box_and_default_zoom_messed_up_while_using_desktop_on_mobile

Makes me think that maybe we are better off simply removing the viewport definition again, because mobile browsers don't seem to be made to handle viewport definitions for things NOT mobile, very well.

Agreed.

Pythoncoder raised the priority of this task from High to Needs Triage.
Pythoncoder added a subscriber: Pythoncoder.

Reopening because this change seems to have caused problems for users viewing the desktop site on mobile. See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Search_box_and_default_zoom_messed_up_while_using_desktop_on_mobile

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

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

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

Seems this too is causing problems: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Search_box_and_default_zoom_messed_up_while_using_desktop_on_mobile

Makes me think that maybe we are better off simply removing the viewport definition again, because mobile browsers don't seem to be made to handle viewport definitions for things NOT mobile, very well.

This is becoming a bit whack-a-mole. The reason we added it for Vector 2022 was that we had people complaining that they were seeing the collapsed table of content rather than the one in the sidebar. 🙃

The fundamental problem here is Vector(s) were never made for mobile and browsers default behaviour seems to be inconsistent and these changes show we can't influence that control. I think it makes sense to remove the logic from core for now, and limit any behaviour changes to Vector 2022 going forward given what we've learned.

So here's what's been learned:

  1. Initial-zoom (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/815765)
  2. Zooms in by default on mobile Chrome
  3. But without if you'll break font scaling on Safari (iPad);
  1. Defining a viewport https://gerrit.wikimedia.org/r/c/mediawiki/core/+/790448
  2. Without one, browsers will do whatever they want which means the table of contents will disappear on Vector 2022 for users on a mobile device. Vector 2022 will become unpredictable with planned font-size changes (T254055) and changes to make the skin more responsive.
  3. With one, more predictable, but zoom level out of our control.

Since we are increasing the font size soon, and migrating towards Vector, I'd rather optimize towards the future at this point.

Here's what I'd suggest:

  1. Revert the core change and accept the behaviour is going to be weird, and point any complaints to this ticket documenting the challenges with retroactively making a desktop skin work on mobile. Could do with some support on the village pumps from community with this one as issues arise relating to Vector 2022 skin and font-size/layout.
  2. Start an RFC around making Vector 2022 responsive by default

@TheDJ would you be able to (or find someone) who would be willing to start a RFC around whether Vector should be responsive? For those who want the existing behaviour, they would have a user preference to opt out (which already exists in the skin preferences) and they can click "Desktop mode" in browser. There's a demo on https://test.wikipedia.org/wiki/Main_Page - there are a few things to fix regarding heading, but if we had an idea on what the community saw as blockers that would be really helpful.

Without one, browsers will do whatever they want which means the table of contents will disappear on Vector 2022 for users on a mobile device.

Just double checking.. That's because the default (desktop) fallback viewport width on mobile devices is something like 980px and the cutoff for vector-2022 is at 1000px ?

But without if you'll break font scaling on Safari (iPad);

I've been thinking if maybe we should tweet about this issue. I'm seriously wondering if it is a bug or expected behaviour and wether or not there is something we can do about it which we are simply unaware of.

Exactly. This task has been an attempt to reverse engineer what browsers do when no viewport tag is specified and all I can conclude so far is it depends on the browser.

I suppose an alternative is to do browser detection and add the zoom via JavaScript...?

Just a thought.. it might be an idea to try user-scalable=yes without the initial scale.

ovasileva raised the priority of this task from Low to Medium.

For what it's worth, the zoomed screen and search bar issue referenced above also happens on Firefox on mobile.