User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

FEATURE REQUEST: Please provide a per-page setting "<menu button>" -> "Page >" -> "Page Scaling" (or similar) to set a different default zoom for a page, e.g. 0.7x (more zoomed out) instead of 1.0x

It is rare but it happens occasionally that some company makes a responsive page and attempts to make things resizable, but screws it up and sets a too small viewport. This, unlike a completely mobile-unaware page, can make it UNUSABLE. This can also happen if a company only tests a page in PORTRAIT but not in LANDSCAPE mode (which is really unavoidable in some more obscure formfactors like the Gemini PDA). On Desktop, even if one resized the window to the same size, CTRL+MINUS can still provide a way to easily make the site usable, but Firefox Mobile has no such option.

Example page:

1. Visit http://bibliothek.carl-schurz-haus.de:2000/#!dashboard in LANDSCAPE(!!) mode
2. Tap "Advanced" and see how unusable the menu is
3. Try to zoom out

Other example: earlier version of discordapp.com that used to set a wrong/too small viewport in tags

This is a huge problem when relying on firefox for android ONLY (e.g. when using an Android device as mobile productivity device) and encountering such a site. For these cases, such a setting would be a game changer

Actual results:

On broken sites that try to adjust to phone screen and cramp things too tightly doing so, there is no way to zoom out past 1.0x

Expected results:

A menu setting or similar should be available to override base zoom for such websites

I forgot to mention, when using HDMI (which is uncommon for android but supported by some recent devices) all pages will generally be way too large in mobile mode, since they assume a small cramped phone screen. Using the desktop page can help, but sometimes that causes things to be then again way too small. Therefore, such a base scalar setting would here also be an absolute game changer in how usable Android is for more productive, serious work

I'm generalizing this bug to also cover the alternative suggestion made in bug 1540811 for how the reflowing zoom behaviour could be activated.

So, to try to summarize, what's being suggested here is some mechanism for the user to activate reflowing zoom (i.e. the kind of zoom that Ctrl+Minus does on desktop, where we reflow the page contents into a different width) on mobile.

Two use cases have been presented:

Use case 1: On a small number of websites which are not designed with mobile devices in mind, the page layout can be very crowded without the ability to reflow-zoom out, making the page difficult to use.

The sort of website that's affected has been described as follows:

it tends to be niche non-IT company pages that are badly done and badly tested, which you usually need once in a lifetime but when you DO need them it tends to be quite a showstopper that you can't use them at all

The only current example that has come up so far is http://bibliothek.carl-schurz-haus.de, though it was mentioned that a past version of discordapp.com was affected.

Use case 2: When connecting an Android device to a desktop monitor via HDMI, then on most websites the screen space is under-utilized and page elements are very lage. Being able to reflow-zoom out would allow the browser to better utilize the larger amount of available screen space.

In terms of a mechanism for activating reflowing zoom, two suggestions have been made:

Mechanism 1: A setting in the hamburger menu (likely in the "Page" section) to increase or decrease the reflowing zoom scale. It could be similar to the "Zoom" entry in Firefox desktop's hamburger menu.

Mechanism 2: Have the pinch-zoom gesture, which triggers the mobile browser's current, non-reflowing zoom, start to trigger reflowing zoom if you're zoomed out to the smallest zoom level that's currently allowed, and you continue to perform the gesture. This could be accompanied by some sort of UI affordance to indicate when you've reached the limit of non-reflowing zoom, so that if a user doesn't wish to proceed to the reflowing zoom phase, they know when to stop pinching. (A specific suggestion for such an affordance was made here.)

jonas, is comment 4 an accurate and fair characterization of your request?

kats, do you think comment 4 provides enough details for UX to make an informed decision?

A nice summary, thanks so much for your work so far!

Yeah I think comment 4 is pretty comprehensive. Although I would have used "Ctrl-Minus" rather than "Ctrl-Plus" as the example since we're only concerned with zooming out and not zooming in.

Hey Bram, we'd like some UX input on a suggested change to Firefox for Android that has UX impact.

The suggested change is described in comment 4 above. We would like feedback on:

• whether the described use cases provide sufficient motivation for introducing a way to perform reflowing zoom in the first place; and
• if so, which of the proposed mechanisms for triggering it would be preferred (or perhaps a different one altogether)

Could you route this request to someone who would be able to provide such an opinion? Thanks in advance!

Hi Botond, this is an issue that we should look at as a part of the larger work around accessibility.

Have other Android browsers implemented this feature? If yes, we should document their methods and learn from them. If no, we should understand why they don’t do it.

Is there sufficient motivation to introduce this feature? Yes. However, we are also committed to deliver Fenix on time, so will only have the chance to work on this after the app has launched.

Which proposed mechanism would work? #2 feels more natural, and #1 is more conventional. A problem I foresee is how to make this mechanism discoverable. You can argue that only users who have this problem would care to find a solution. Perhaps the mechanism doesn’t need to be put in front of your face all the time.

I will redirect this request to Amy and Stephen for future consideration. In the meantime, I’d love it if you can post an explanation about what reflow vs. non-reflow zoom is, and how they both work. The more visual, the better!

(In reply to Bram Pitoyo [:bram] from comment #9)

I will redirect this request to Amy and Stephen for future consideration. In the meantime, I’d love it if you can post an explanation about what reflow vs. non-reflow zoom is, and how they both work. The more visual, the better!

I assume this is the difference between pinch to zoom 1:1 scaling and actually changing the layout by re-flowing the content?

Leaving my NI on this, but as Bram mentioned UX doesn't have the bandwidth to take this on right now.

Thanks!

(In reply to Stephen Horlander [:shorlander] (If you're waiting on a response please ping me on Slack or IRC) from comment #10)

(In reply to Bram Pitoyo [:bram] from comment #9)

I will redirect this request to Amy and Stephen for future consideration. In the meantime, I’d love it if you can post an explanation about what reflow vs. non-reflow zoom is, and how they both work. The more visual, the better!

I assume this is the difference between pinch to zoom 1:1 scaling and actually changing the layout by re-flowing the content?

Yep, that's right. Reflowing zoom is what the desktop browser does in response to Ctrl+Plus/Ctrl+Minus, and it involves changing the layout, while non-reflowing zoom is what the mobile browser currently does in response to a pinch gesture (no change to the layout, just scale).

If you'd like a visual illustration, this video does a pretty decent job:

https://www.youtube.com/watch?v=OxYW7ynDUrc

In that video, the right-hand side shows a non-reflowing zoom, and the the left-hand side shows a reflowing zoom.

(Note, that video illustrates a different use case (reflowing when zooming in to make an article more readable by wrapping text lines) which we've addressed in a different way (Reader Mode), but the concept of reflowing vs. just scaling is the same.)

i'm surprised so far here there's no mention that opera beta has had this feature for quite some time, not to mention as a result that makes it the browser i use daily. i'd really prefer to use nightly android firefox, but i consider reflow essential. i recommend you have a look at the utter simplicity of the opera beta implementation (in stark contrast to the above discussion). i always turn on two simple settings, enable zoom on all pages, and enable reflow on zoom. Simple. And all zooms, in or out, then do reflow. i consider this essential because i find it quite commonplace to find pages that are unreadably tiny. Mozilla bugzilla for an example. And after zooming in sufficiently to be able to read the text, having to pan back and forth to read the page is absurd.

I'm pretty sure issue 1807123 is a duplicate of this https://bugzilla.mozilla.org/show_bug.cgi?id=1807123

I'm going to reopen this because I think it's still potentially relevant.

We have bug 1547181 on file to track the capability to invoke reflow-zoom on mobile more generally; I'm going to mark this as dependent on that since it may still be interesting to explore different UX options for how to activate it as discussed in comment 4.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:cpeterson, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.