Closed Bug 789906 (desktop-zoom-win) Opened 12 years ago Closed 4 years ago

When using touch UI (for example on Win8), zooming shouldn't reflow, but just scale

Categories

(Core :: Panning and Zooming, enhancement, P3)

Product:
Core
Component:
Panning and Zooming
Platform:
x86
Windows 10
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1620056
Tracking Flags:
Tracking Status
firefox48 --- wontfix
firefox-esr78 --- wontfix
firefox82 --- wontfix
firefox83 --- fixed
firefox84 --- fixed
firefox85 --- fixed

People

(Reporter: smaug, Unassigned)

References

(Depends on 1 open bug, Blocks 4 open bugs)

Details

(Keywords: feature, Whiteboard: gfx-noted)

Right now zoom behavior on Win8+touchscreen is less than optimal.
OS: Linux → Windows 8
Isn't this basically a dupe of bug 593168?
Depends on: 593168
Depends on: 766142
Blocks: 814476
No longer depends on: 766142
No longer blocks: 814476
Blocks: apz-desktop
No longer blocks: desktop-zoom-mac
No longer blocks: apz-desktop
Depends on: apz-desktop
Any status update on this bug? This missing feature makes Firefox seem outdated compared to IE 11...especially on PC+ devices like my Surface Pro 2.
Mmhmm... This should be a high-priority improvement -- Make sure to vote for it, at the least...
Wasn't aware of the voting system. I've voted, sure hope this gets addressed…or just bring back the Windows 8 mode you were originally planning. I, like many others, ditched FireFox earlier 'cause the asinine version number race kept breaking compatibility with extensions. That appears to have been fixed, and I'm back to using Firefox.
No longer blocks: 1180706
Depends on: 1180706
Component: Layout → Panning and Zooming
Once bug 1180706 gets merged to m-c, you can enable the Android-style pinch-zooming behaviour by setting apz.allow_zoom=true and dom.meta-viewport.enabled=true. However doing that will break the UI in rather bad ways, so we need to fix things up before we can do that by default.
Keywords: feature
Whiteboard: gfx-noted
Bit surprised at the lack of chatter on a 5 year old bug. :) Anyway, was reading this post... https://www.reddit.com/r/firefox/comments/6s7m1f/firefox_needs_actual_touch_support_on_desktop/ Which I think makes a fair point that [it's 2017 and] the other major browsers meet users expectations that touch-zooming scales the entire page (like a tablet or a phone would). Notably we seem to be taking touch seriously now by adding a Touch Mode to the UI - even automatically invoking it when Windows itself goes into touch mode. I do hope we can reprioritize this as a result. Oh, I did try the steps kats outlined in comment 9 to see how things would go. They went poorly.
Needinfo for this. kats, do you have an overview of the work items that are left to make this work properly? :) Thanks!
Flags: needinfo?(bugmail)
Not offhand. However it's not a trivial fix, there is a fair amount of work needed in the guts of layout and graphics code.
Flags: needinfo?(bugmail)
Platform only lists Windows8 and x86 but Windows10 and x64 are affected, too. I recently switched from an Android based tablet to a Windows10 one and this really is the main annoyance.
Now that 57 is near the door, thought I'd ping this bug as a reminder. I still see requests for this in other forums like reddit and IRC. Here's one post from today with some upvotes and agreeing comments. https://www.reddit.com/r/firefox/comments/789d4d/will_firefox_ever_get_pinch_zoom/ One comment in particular says: > 100% agree. This is an accessibility need for me. I am visually impaired and pinch to zoom in chrome helps so much compared to just using CTRL+ +/-. As soon as FireFox has this, I'll switch. I can certainly understand how the current jumpy behavior and shifting layout could be considered a non-starter for someone who is visually impaired (while other browsers do this fine). Considering this an accessibility aspect may change our perspective a bit too.
Actually changing the platform to All here, as this also affects trackpad zooming on macOS.
OS: Windows 10 → All
Bug 688990 is the macOS version; this one is for windows only. The code for the two will not be the same, because on macOS the manipulation is indirect via a trackpad whereas on windows it would be direct via touchscreen. By "direct" I mean the input device is also the output device so the zoom focus will be based on the user's touch position while for the "indirect" case the zoom focus will always by centred.
OS: All → Windows 10
See Also: → desktop-zoom-mac
Seems like the two implementations might end up sharing code (I could be wrong of course). If so, implementors will want to coordinate.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #17) > Bug 688990 is the macOS version; this one is for windows only. The code for > the two will not be the same, because on macOS the manipulation is indirect > via a trackpad whereas on windows it would be direct via touchscreen. By > "direct" I mean the input device is also the output device so the zoom focus > will be based on the user's touch position while for the "indirect" case the > zoom focus will always by centred. What about windows devices that don't have touchscreens, but do have precision trackpads? (e.g. Dell XPS 13), or is that a separate bug? These devices support indirect zooming on the trackpad in Microsoft Edge (just like macbook trackpads do with Safari/OSX)
(In reply to Brandon Watkins from comment #19) > What about windows devices that don't have touchscreens, but do have > precision trackpads? (e.g. Dell XPS 13), or is that a separate bug? These > devices support indirect zooming on the trackpad in Microsoft Edge (just > like macbook trackpads do with Safari/OSX) In practice fixing either direct or indirect zooming will take a significant effort and the patches will be spread over multiple bugs. Most likely this bug will just end up being used to flip the pref that turns on the feature. Until the implementation is done I don't know if windows trackpad support will be covered by this bug or the other one or some third bug. There is certainly code that will need to be written to handle that case that is not strictly required for either direct zooming on windows or indirect zooming on macOS. However depending on how the implementation goes the code might get written as part of those features.
Wanted to say that WebRender may enable buttery smooth zooming. If this is the case, pinch-to-zoom could make for an excellent showcase for it. I hope, then, it would be possible to land at the same time as WebRender hits release. Would smooth zooming need any sort of special integration with WebRender?
Im the pre-precision days, used to cheat smooth scrolling on trackpads in Windows by setting the global scroll increment to 1 line (instead of the default 3). Although a true fix to this bug appears to require some heavy lifting, could a possible interim solution call modified versions of the `enlarge()`/`reduce()` `zoomManager` methods that use a set of finer-grained `zoomValues` when using touch input (e.g., 0.98, 0.99, 1, 1.01, 1.02, ... instead of the default 0.9, 1, 1.1, ...)? I just tested it on my XPS and while it's not perfect, it's an improvement. That said, there'd have to be a separate solution for touchpads, since it appears they're treated as `mousewheel.with_control` inputs.
It's possible have smooth multi-touch magnification zooming in current Firefox (pre WebRender), I've published an extension to demo https://addons.mozilla.org/en-GB/firefox/addon/multi-touch-zoom/ I've only tested on Macbook trackpads but I'm expecting it to work on touch-screen Windows devices – do these devices bind pinch to increment zoom increment by default? If so that may need to be unbound
Yeah, unfortunately it doesn't appear to work with Windows (I filed a bug on GitHub). If anyone has any thoughts and I can try to take a crack at it.
My mistake! It does work when you hold shift while scrolling, but not with touchpad pinching or the touchscreen. I think other mappings might have priority when those events occur.
@haxiomic ; tried on windows and works only with touchpad + SHIFT key pressed . I'm so happy that there is at least one way to scale zoom to works ! I added a comment on this issue here https://github.com/haxiomic/firefox-multi-touch-zoom/issues/1 Thanks for the work, I'm sure we will have an extension to scale zoom with pinch on touch screen very soon ! Hope so anyway, it's been a killer feature for me and I don't use Firefox only because of that. (I use the brower to teach at my university and need to scale zoom many times to show things on screen). Excited to see that's moving 6 years after !! nd I hope to use firefox soon again !
@haxiomic's extension now works with touchscreen
Depends on: desktop-zoom-xp
It's not inactive, but there are a number of architectural issues blocking this feature. See the transitive dependencies of this bug, and particularly the dependencies of bug 1461360. A lot of work was done on bug 656036, and it's close to being done. The next big piece to be tackled will be bug 1459312, which I hope to work on in the coming months.
https://blog.mozilla.org/futurereleases/2018/12/06/firefox-coming-to-the-windows-10-on-qualcomm-snapdragon-devices-ecosystem/ This was just announced today, all of these devices will have touchscreens. Perhaps Qualcomm can help getting this shipped sooner? This issue is not a P3, it's a P2, please change this to P2
I'm doing my best to advocate for this feature and get it on the roadmap for 2019 Q1 (and meanwhile, I have been working on bug 1459312, which is one of its important dependencies). It's not forgotten :)
Thank you! 6 years is painful for something like this :(

Thanks for the updates on this. I am currently using MOZ_USE_XINPUT2=1 on Linux to at least have smooth scrolling with my touchscreen. Is this already using APZ or is this some hacky workaround, which kinda just works for now?

Are the changes discussed here also affecting Linux or just the Windows platform? For the zooming there are a few suboptimal addons like https://addons.mozilla.org/en-US/firefox/addon/multi-touch-zoom/ which work on Linux using XINPUT2 but since they just translate the document body, they break touch gestures within websites.

One more question related to this, the only good resource I can find about APZ is https://wiki.mozilla.org/Platform/GFX/APZ but it feels quite outdated. Is there something better to follow the progress or is this just due to few resources working on this issue?

(In reply to Johannes Zellner from comment #39)

I am currently using MOZ_USE_XINPUT2=1 on Linux to at least have smooth scrolling with my touchscreen. Is this already using APZ or is this some hacky workaround, which kinda just works for now?

Yep, this is using APZ. It's just not enabled by default, due to the issues blocking bug 1207700.

Are the changes discussed here also affecting Linux or just the Windows platform?

They will affect both Windows and Linux.

(In reply to Johannes Zellner from comment #40)

One more question related to this, the only good resource I can find about APZ is https://wiki.mozilla.org/Platform/GFX/APZ but it feels quite outdated. Is there something better to follow the progress or is this just due to few resources working on this issue?

I can point you to technical documentation about APZ, but that's not really useful for following this issue. The best way to follow progress on this issue is to follow bugs in its dependency tree. At this time, the dependency I'm actively working on continues to be bug 1459312.

Thanks for the quick and elaborate reply. I would love to help with this issue, but I have never coded for firefox. I will first try to figure how to build and run it from source and can at least offer to test any changes if wanted.
I can test on both wayland (my default since some time) and X11 with a touchscreen and touchpad.

(In reply to Johannes Zellner from comment #42)

I would love to help with this issue, but I have never coded for firefox. I will first try to figure how to build and run it from source and can at least offer to test any changes if wanted.

Cool, thanks!

Note that you don't necessarily need to build Firefox yourself to test out changes. Code will start to land on the Nightly channel behind a pref, so if you just run an up-to-date Nightly and flip relevant prefs in about:config, you can test things without having to build.

I can test on both wayland (my default since some time) and X11 with a touchscreen and touchpad.

One thing to note is that the initial support will be for touchscreens. Pinch-zooming on the touchpad will require a bit of additional work (and separate work for Windows and Linux).

Blocks: fx-touch
No longer blocks: 1158152

The Addon zooms very unresponsive for me on Windows 10. Any update on when smooth scale zooming will be implemented? Q1 of 2019 has already passed.

This feature did get onto the roadmap, and we made progress in Q1 by fixing one of the main architectural dependencies (bug 1137890). I will be continuing to work on it in Q2.

Note that being on the roadmap for a given quarter does not mean being done or released in that quarter, it means development time will be spent on it in that quarter. The total amount of development time needed, and therefore the shipping date, is not certain at this point.

quick question about this: when it's 'finished', will the scrollbars update when you zoom in or out via touchscreen? The EdgeHTML based Edge does this but Chromium still doesn't https://bugs.chromium.org/p/chromium/issues/detail?id=456861

The end goal is to have the full range of scrollbar behaviour with zooming, including updating their size appropriately, dragging them, and so on.

In the interest of getting this feature in front of users sooner, we may enable it by default before reaching that end goal.

Type: defect → enhancement
Depends on: 1556081
Blocks: 1568676
Blocks: 1569189

Is there a rough ETA for touchscreen zoom on Windows 10?

I'm continuing to actively work on this.

I'm currently working on changes related to scrollbar dragging (bug 1556556). They're turning out to be tricker than anticipated, as discussed in bug 1556556 comment 19 and subsequent comments.

If you don't care about scrollbar dragging, you could try the feature already by going to about:config and setting apz.allow_zooming to true. My understanding is that some early adopters have been using it (see the "Pinch to zoom" section in this Reddit thread) and apart from some known issues (such as scrollbar dragging, and the issue mentioned about add-on popups in that thread, which I've actually since fixed) it seems to be working fine for them.

Note that on Windows, this is only hooked up for touchscreens at this time (not touchpads).

Pinch zoom works great on my Mac, with a few caveats:

  1. When I zoom in then try to scroll side to side using two fingers on the trackpad, Firefox starts to go forward or back in history instead of scrolling. In Safari, the page scrolls until it reaches the edge of the page, then starts to go forward or back. Workaround is to scroll up or down a bit first, then scroll sideways (or just disable the forward/back gestures in about:config).
  2. I find Safari's double-tap with two fingers gesture to zoom in/out on a block of text to be very useful. It appears that Firefox doesn't have this yet.

Are either of these currently on the radar?

(In reply to lhagan from comment #50)

Pinch zoom works great on my Mac, with a few caveats:

  1. When I zoom in then try to scroll side to side using two fingers on the trackpad, Firefox starts to go forward or back in history instead of scrolling. In Safari, the page scrolls until it reaches the edge of the page, then starts to go forward or back. Workaround is to scroll up or down a bit first, then scroll sideways (or just disable the forward/back gestures in about:config).

Could you file a bug for this please?

  1. I find Safari's double-tap with two fingers gesture to zoom in/out on a block of text to be very useful. It appears that Firefox doesn't have this yet.

Are either of these currently on the radar?

This one is tracked in bug 674371.

(In reply to Botond Ballo [:botond] from comment #51)

Could you file a bug for this please?

Done, see bug 1591799.

This actually works very nicely now on Linux/wayland for my touchscreen. Great work! :-)
Are there any settings I could try to see if it also works with a multitouchpad?

Only caveat I can currently experience is the sometimes very slow rerendering of the viewport when coming from high zoom levels.

That last comment triggered the thought: Are we going to need new tests for zoom? Stuff like measuring render performance after zoom in/out? Or that content doesn't break before/after.

Also btw enabling this on Linux/wayland still breaks extension popups to be shown as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1522131

From the toolbar other popups like the sync account popup work just fine. So maybe there is some default size missing if apz is enabled? Just a very wild guess.

(In reply to Johannes Zellner from comment #53)

Are there any settings I could try to see if it also works with a multitouchpad?

Unfortunately not, it has not been hooked up for Linux touchpads yet. Bug 1581126 tracks.

Only caveat I can currently experience is the sometimes very slow rerendering of the viewport when coming from high zoom levels.

Yeah, the feature will likely need some tuning. It is reusing the mobile pinch-zooming infrastructure which thus far has been tuned for mobile screen sizes.

(In reply to Caspy7 from comment #54)

Are we going to need new tests for zoom? Stuff like measuring render performance after zoom in/out?

Yes, some performance tests for desktop zooming will be useful.

Or that content doesn't break before/after.

For this, I think our existing tests for pinch-zooming on mobile should provide test coverage. However, if we come across desktop-specific issues that don't occur on mobile, then tests for them will be useful as well.

(In reply to Johannes Zellner from comment #55)

Also btw enabling this on Linux/wayland still breaks extension popups to be shown as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1522131

Are you testing with latest nightly? The extension popup issue was only fixed a few days ago.

If so, please file a new bug with STR (or feel free to reopen bug 1522131).

(In reply to Botond Ballo [:botond] from comment #58)

(In reply to Johannes Zellner from comment #55)

Also btw enabling this on Linux/wayland still breaks extension popups to be shown as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1522131

Are you testing with latest nightly? The extension popup issue was only fixed a few days ago.

If so, please file a new bug with STR (or feel free to reopen bug 1522131).

Oh indeed, I can confirm this is fixed in nightly already. I was on developer version. Awesome work!

Works nicely on Windows 10, maybe the PDF.js could be edited in manor so the top PDF bar is always visible when zooming (in other words zooming just the content, not whole PDF.js, as other browsers do).

I found another bug on Linux/Wayland. When apz.allow_zoom=true switching between HiDPI and non HiDPI monitors results in page viewports having the wrong size within the tab which was zoomed. Not even a page reload fixes it, also not resizing the browser window nor restarting the browser altogether. Zooming withing the wrongly sized viewport still works as expected but the frame simply has a persistent right and bottom padding. Is there any tool to view the tab properties, where the frame size might be stashed away?

Sorry if this does not have much technical detail for further debugging, but I am not sure what to provide.

(In reply to Johannes Zellner from comment #61)

I found another bug on Linux/Wayland. When apz.allow_zoom=true switching between HiDPI and non HiDPI monitors results in page viewports having the wrong size within the tab which was zoomed. Not even a page reload fixes it, also not resizing the browser window nor restarting the browser altogether. Zooming withing the wrongly sized viewport still works as expected but the frame simply has a persistent right and bottom padding. Is there any tool to view the tab properties, where the frame size might be stashed away?

Please file a new bug with this information, so we don't forget about it. Thanks!

(In reply to Botond Ballo [:botond] [standards meeting Nov 4-9] from comment #62)

(In reply to Johannes Zellner from comment #61)

I found another bug on Linux/Wayland. When apz.allow_zoom=true switching between HiDPI and non HiDPI monitors results in page viewports having the wrong size within the tab which was zoomed. Not even a page reload fixes it, also not resizing the browser window nor restarting the browser altogether. Zooming withing the wrongly sized viewport still works as expected but the frame simply has a persistent right and bottom padding. Is there any tool to view the tab properties, where the frame size might be stashed away?

Please file a new bug with this information, so we don't forget about it. Thanks!

https://bugzilla.mozilla.org/show_bug.cgi?id=1594071

For those of you interested in touchpad support on Windows or Linux -- does it work in any other browsers, such as Chrome or Edge? If it does, could you mention what model of laptop (or external touchpad hardware) you have?

Zooming through touchpad works on Surface 3 (non-pro) on the new Chromium-based Microsoft Edge. (Edit: Works on Chrome too.)

(In reply to Botond Ballo [:botond] from comment #64)

For those of you interested in touchpad support on Windows or Linux -- does it work in any other browsers, such as Chrome or Edge? If it does, could you mention what model of laptop (or external touchpad hardware) you have?

Works for me on windows in both Chrome and Edge. XPS 15 (9560) and Surface Pro 3. Is there any additional information there that would be helpful? (happy to test stuff on both windows and linux for both machines :) )

Don't remember any browser on Linux (wayland or xorg) that has pinch to zoom hooked up, but AFAIK GTK has some native support for it as just a passthrough from the platform provided events.

(In reply to Sawyer Bergeron from comment #66)

Works for me on windows in both Chrome and Edge. XPS 15 (9560) and Surface Pro 3. Is there any additional information there that would be helpful? (happy to test stuff on both windows and linux for both machines :) )

Weird, on a Surface Pro 2 (which has a high precision touch pad) in Chrome I get reflow zooming, not scaling. I wonder what is causing the difference.

In IE on the Surface Pro 2 I get scaling from the touchpad, and reflow zoom if I plug in a wireless keyboard that has a touchpad on it (presumably not a high precision touchpad).

Any ETA on this? I would really love to switch from Chrome to Firefox but it is unusable because of this issue on touch displays. It's 2020. iPhone could do this in 2007!

Regarding touchpads, Microsoft explained here how they solved it for Edge: https://blogs.windows.com/msedgedev/2017/12/07/better-precision-touchpad-experience-ptp-pointer-events/

https://bugzilla.mozilla.org/show_bug.cgi?id=789906#c49 explains how to enable pinch to zoom for touchscreens (not touchpads yet) on Windows.

(In reply to Kagami :saschanaz from comment #70)

https://bugzilla.mozilla.org/show_bug.cgi?id=789906#c49 explains how to enable pinch to zoom for touchscreens (not touchpads yet) on Windows.

Thanks! That somewhat works. It is not as smooth as in other browsers but it is good enough. Looking forward for the touchpad to get fixed as well.

We are looking at getting this working with precision touchpads; you can follow bug 1568676 for details.

Alias: desktop-zoom-win
No longer blocks: 1568676
Depends on: 1568676

Was just wondering what the status of this is, is it shipping soon?

It can be enabled on Nightly by setting the following prefs:

  • touchscreens: apz.allow_zooming=true
  • precision touchpads: apz.allow_zooming=true and apz.windows.use_direct_manipulation=true

To follow the progress of shipping the feature, you can follow the tracking bugs for enabling by default on the nightly channel and letting the feature ride to the release channel.

(In reply to Will from comment #73)

Was just wondering what the status of this is, is it shipping soon?

I'm following one of the bugs that botond mention and have noticed that dependent bugs keep getting fixed. So if part of your question is, "Is work ongoing to actually fix this?" It seems the answer is yes.

There's a small issue with this type of zoom replacing the previous type (it's not specific to Firefox, I think it's just a downside of this type of zoom): though rare, sometimes I find myself wanting to zoom OUT via touchscreen (90%, 80% etc.). The new style of zooming doesn't allow this. I know it's not commonly needed/desired but would this even be possible to do? If so, I'll file a bug for it.

Is this possible?: when fully zoomed out with scale zoom, if it senses the user is zooming out on their touchscreen/touchpad, it could switch to using the reflow style zoom? And you would see the "90%", "80%" page zoom indicator etc. pop up in the URL bar

(In reply to Will from comment #76)

There's a small issue with this type of zoom replacing the previous type (it's not specific to Firefox, I think it's just a downside of this type of zoom): though rare, sometimes I find myself wanting to zoom OUT via touchscreen (90%, 80% etc.). The new style of zooming doesn't allow this. I know it's not commonly needed/desired but would this even be possible to do? If so, I'll file a bug for it.

You should still be able to tap the menu button and adjust the zoom level.

(In reply to Kagami :saschanaz from comment #77)

(In reply to Will from comment #76)

There's a small issue with this type of zoom replacing the previous type (it's not specific to Firefox, I think it's just a downside of this type of zoom): though rare, sometimes I find myself wanting to zoom OUT via touchscreen (90%, 80% etc.). The new style of zooming doesn't allow this. I know it's not commonly needed/desired but would this even be possible to do? If so, I'll file a bug for it.

You should still be able to tap the menu button and adjust the zoom level.

I know, was just wondering if something could be done with touchscreen zooming out. It's much more natural and intuitive than tapping menu and tapping zoom out button

(In reply to Will from comment #76)

There's a small issue with this type of zoom replacing the previous type (it's not specific to Firefox, I think it's just a downside of this type of zoom): though rare, sometimes I find myself wanting to zoom OUT via touchscreen (90%, 80% etc.). The new style of zooming doesn't allow this. I know it's not commonly needed/desired but would this even be possible to do? If so, I'll file a bug for it.

Is this possible?: when fully zoomed out with scale zoom, if it senses the user is zooming out on their touchscreen/touchpad, it could switch to using the reflow style zoom? And you would see the "90%", "80%" page zoom indicator etc. pop up in the URL bar

You can try the pref apz.allow_zooming_out, I'm not too familiar with it, so it might not do anything for the situation you are talking about.

Nothing really seems to use apz.allow_zooming_out per my Searchfox result, though.

apz.allow_zooming_out allows zooming out past the initial zoom in cases where the page content is wider than the browser window. However it sounds like the case you're interested in may not satisfy that requirement. It's worth filing a bug for the case you described, it should be possible to switch to reflow zoom out in cases where you can't pinch zoom out.

Wow, apz.allow_zooming_out is fantastic! Chromium doesn't have this, does Safari? If this is exclusive to Firefox, whoever thought of this deserves a raise haha. Honestly, I think apz.allow_zooming_out is the solution, thank you. I really hope it makes it through to release! What I described above seems a bit messy and confusing, assuming it would even be possible, so I don't think I'm going to bother filing it.

My brother convinced me to file it https://bugzilla.mozilla.org/show_bug.cgi?id=1650596

Btw, is apz.allow_zooming_out going to be hooked up to the page zoom percentage indicator that appears in the URL bar? It seems like it should appear when you zoom out beyond 100%

(In reply to Will from comment #84)

Btw, is apz.allow_zooming_out going to be hooked up to the page zoom percentage indicator that appears in the URL bar? It seems like it should appear when you zoom out beyond 100%

No plans for that at the moment. We also don't show any indicator when you're zoomed in.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #85)

(In reply to Will from comment #84)

Btw, is apz.allow_zooming_out going to be hooked up to the page zoom percentage indicator that appears in the URL bar? It seems like it should appear when you zoom out beyond 100%

No plans for that at the moment. We also don't show any indicator when you're zoomed in.

To expand on this a bit: the current zoom indicator only ever shows the reflowing-zoom level. Note that you can combine reflowing-zoom with scaling-zoom, so you can e.g. pinch-zoom in to 1.5x, and press Ctrl+Plus to increase the reflow-zoom level to 110%, and the indicator would appear and show 110%.

I don't think it makes sense to try to combine the two zoom levels into a single numerical indicator, as they behave quite differently. We could, however, consider having a separate indicator for the scaling-zoom level.

Is apz.allow_zooming_out not supported on Windows? Seems it has no effect on my machine. (Sorry for my previous mislead 🤯)

(In reply to Botond Ballo [:botond] from comment #86)

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #85)

(In reply to Will from comment #84)

Btw, is apz.allow_zooming_out going to be hooked up to the page zoom percentage indicator that appears in the URL bar? It seems like it should appear when you zoom out beyond 100%

No plans for that at the moment. We also don't show any indicator when you're zoomed in.

To expand on this a bit: the current zoom indicator only ever shows the reflowing-zoom level. Note that you can combine reflowing-zoom with scaling-zoom, so you can e.g. pinch-zoom in to 1.5x, and press Ctrl+Plus to increase the reflow-zoom level to 110%, and the indicator would appear and show 110%.

I don't think it makes sense to try to combine the two zoom levels into a single numerical indicator, as they behave quite differently. We could, however, consider having a separate indicator for the scaling-zoom level.

I got confused because of this: right now in Nightly I went to https://en.wikipedia.org/wiki/Main_Page with apz.allow_zooming_out enabled. I made the window small but the page zoom level is still at default 100%. I zoom out via touchscreen pinch gesture (because apz.allow_zooming_out is enabled and I made the window really small) but the page zoom indicator hasn't triggered. This just seems wrong... Maybe there really should be a separate page zoom indicator for the scale type of zoom for this type of scenario, even though that's confusing I think it would be wrong to not have that.

(In reply to Botond Ballo [:botond] from comment #86)

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #85)

(In reply to Will from comment #84)

Btw, is apz.allow_zooming_out going to be hooked up to the page zoom percentage indicator that appears in the URL bar? It seems like it should appear when you zoom out beyond 100%

No plans for that at the moment. We also don't show any indicator when you're zoomed in.

To expand on this a bit: the current zoom indicator only ever shows the reflowing-zoom level. Note that you can combine reflowing-zoom with scaling-zoom, so you can e.g. pinch-zoom in to 1.5x, and press Ctrl+Plus to increase the reflow-zoom level to 110%, and the indicator would appear and show 110%.

I don't think it makes sense to try to combine the two zoom levels into a single numerical indicator, as they behave quite differently. We could, however, consider having a separate indicator for the scaling-zoom level.

Sorry to double post but I am confused about something, you said it's not a good idea to try to combine the two zoom levels into a single thing (I agree, btw) but haven't you done exactly that for the scrollbars? The scrollbars are indeed supposed to update for scale-zooming but you're using 1 scrollbar for both scale zooming and reflow zooming. It would look ridiculous but wouldn't it be "correct" to have 2 scrollbars, 1 for each type of zoom? For example, go to google.com, zoom in via touchscreen until horizontal scrollbar appears, now reflow zoom in and notice that same scrollbar updates. That seems really confusing and wrong? Maybe scale-zoom should have a mobile-style overlay scrollbar instead so it wouldn't look as ridiculous (2 scrollbars beside each other at times) and it wouldn't take up as much space.

(In reply to Kagami :saschanaz from comment #87)

Is apz.allow_zooming_out not supported on Windows? Seems it has no effect on my machine. (Sorry for my previous mislead 🤯)

It should work on Windows, assuming you're running nightly and have the prefs for comment 74 set as well.

However, note that, as explained in comment 82, zooming out will only work if the page content is wider than the browser window at 1.0 zoom (i.e. if there is a horizontal scrollbar at 1.0 zoom). For many pages that's not the case (since the content width is often sized to fit the browser window's width).

(In reply to Will from comment #88)

I got confused because of this: right now in Nightly I went to https://en.wikipedia.org/wiki/Main_Page with apz.allow_zooming_out enabled. I made the window small but the page zoom level is still at default 100%. I zoom out via touchscreen pinch gesture (because apz.allow_zooming_out is enabled and I made the window really small) but the page zoom indicator hasn't triggered. This just seems wrong... Maybe there really should be a separate page zoom indicator for the scale type of zoom for this type of scenario, even though that's confusing I think it would be wrong to not have that.

I understand the desire for a scale-zoom level indicator.

But just to clarify: there's nothing special about zooming out here, right? I would expect the scenario you describe is no more confusing than the fact that pinch-zooming in doesn't cause any zoom indicator to appear.

(In reply to Will from comment #89)

Sorry to double post but I am confused about something, you said it's not a good idea to try to combine the two zoom levels into a single thing (I agree, btw) but haven't you done exactly that for the scrollbars? The scrollbars are indeed supposed to update for scale-zooming but you're using 1 scrollbar for both scale zooming and reflow zooming. It would look ridiculous but wouldn't it be "correct" to have 2 scrollbars, 1 for each type of zoom? For example, go to google.com, zoom in via touchscreen until horizontal scrollbar appears, now reflow zoom in and notice that same scrollbar updates. That seems really confusing and wrong? Maybe scale-zoom should have a mobile-style overlay scrollbar instead so it wouldn't look as ridiculous (2 scrollbars beside each other at times) and it wouldn't take up as much space.

You are right to observe that pinch-zooming in creates a situation that has some aspects of the behaviour of two nested scrollable elements. (This page has a nice simulation illustrating it.)

However, showing two sets of scrollbars may just confuse users more than it helps. We haven't seen other browsers doing this, and we have no current plans to do so either.

(In reply to Botond Ballo [:botond] from comment #91)

(In reply to Will from comment #88)

I got confused because of this: right now in Nightly I went to https://en.wikipedia.org/wiki/Main_Page with apz.allow_zooming_out enabled. I made the window small but the page zoom level is still at default 100%. I zoom out via touchscreen pinch gesture (because apz.allow_zooming_out is enabled and I made the window really small) but the page zoom indicator hasn't triggered. This just seems wrong... Maybe there really should be a separate page zoom indicator for the scale type of zoom for this type of scenario, even though that's confusing I think it would be wrong to not have that.

I understand the desire for a scale-zoom level indicator.

But just to clarify: there's nothing special about zooming out here, right? I would expect the scenario you describe is no more confusing than the fact that pinch-zooming in doesn't cause any zoom indicator to appear.

Well, in the scenario I described, there's no way of going back to the default 100% like you can by clicking the reflow page zoom percentage indicator, you wouldn't even really know that you're not at 100%, it seems wrong. In Chromium for WIndows and Chrome for iPad (in Safari for iPad when you zoom out, it zooms out into a tab grid view so Safari can't be used for this), you can zoom out fully with pinch gesture on touchscreen and that's how you know you're at 100%.

(In reply to Will from comment #93)

Well, in the scenario I described, there's no way of going back to the default 100% like you can by clicking the reflow page zoom percentage indicator, you wouldn't even really know that you're not at 100%, it seems wrong. In Chromium for WIndows and Chrome for iPad (in Safari for iPad when you zoom out, it zooms out into a tab grid view so Safari can't be used for this), you can zoom out fully with pinch gesture on touchscreen and that's how you know you're at 100%.

Thanks for clarifying. I agree, having a discoverable mechanism to reliably get back to 100% scale-zoom is one of the things we'll need to figure out before we can release apz.allow_zooming_out.

Not sure if this is a Bugzilla bug or a Firefox bug but please take a look https://bugzilla.mozilla.org/show_bug.cgi?id=1656139

(In reply to Botond Ballo [:botond] from comment #91)

I understand the desire for a scale-zoom level indicator.

I filed bug 1656612 to track discussions around adding a scale-zoom level indicator.

Blocks: 1564022

For anyone who's following this bug but not the more recent tracking bugs like bug 1620056: this feature is slated to be released as part of Firefox 83.

Thank you to everyone who helped test the feature in Nightly, and to everyone else for your patience.

I think we can close this bug now.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

Fantastic. Great job.

Blocks: 1682974
You need to log in before you can comment on or make changes to this bug.