1988388 - In Reader view, pinch zooming via touchpad should be smooth and zoom images (perhaps: not be intercepted in the way accel-mousewheel zoom is)

Status: NEW

(Toolkit :: Reader Mode, defect, P3)

Description

[Will]

Go to any webpage where reader view is available such as https://en.wikipedia.org/wiki/Cat . Enable reader view and then pinch zoom via touchpad. Observe that it does the stepped reflow type of zoom instead of the smooth/precise touchpad type of zoom. It is a poor experience for this reason. Notably, when I pinch zoom via the touch screen in Reader view, it's the smooth/precise style of zoom, which is fantastic.

Device is a Surface Laptop 6 on Windows 11, it has a "precision touchpad"

Comment 1

[Botond Ballo [:botond]]

Moving to Panning and Zooming for initial triage.

Comment 2

[Botond Ballo [:botond]]

This seems to be a deliberate choice made by the Reader View implementation, which registers a wheel event listener, and calls preventDefault() on wheel events with the Ctrl modifier set, which is what the browser generates in response to a touchpad pinch gesture. This instructs the browser not to perform its default behaviour in response to the gesture (which would be to do a smooth/non-reflowing zoom). The Reader View implementation then reacts to the event itself by changing the font size, which has the effect of reflowing the page contents.

I will note however that this functionality dates back to 2019 (implemented in bug 1557256), at which time the browser default behaviour was also reflowing zoom, and the difference between the browser default behaviour and the custom behaviour was that the custom behaviour would not change the size of the Reader View controls, only the page content.

Now that the browser default behaviour is to do non-reflowing zoom, maybe the Reader View implementation is better off just letting it happen? Moving the bug to Toolkit :: Reader Mode for further triage.

Comment 3

[Botond Ballo [:botond]]

(In reply to Will from comment #0)

Notably, when I pinch zoom via the touch screen in Reader view, it's the smooth/precise style of zoom, which is fantastic.

For completeness, the reason pinch-zoom via the touch screen has different behaviour is that this generates a different type of event (a touch event with multiple touch points, rather than a wheel event with the Ctrl modifier set), and the Reader View implementation does not listen for and preventDefault() touch events. (It could, if it wanted to react to touchscreen pinch-zoom gesture the same as touchpad pinch-zoom gestures for consistency.)

Comment 4

[Botond Ballo [:botond]]

One potential challenge here is that there is no way to distinguish between "touchpad pinch gesture" and "mousewheel scroll with the Ctrl keyheld down" in JS code (they both produce "wheel event with the Ctrl modifier set"). So, if the Reader View implementation were to stop preventDefault()'ing wheel events with the Ctrl modifier set, we would now not only get the browser default behaviour for touchpad pinch gestures (which is non-reflowing zoom), we'd also get the browser default behaviour for Ctrl+mousewheel, which is reflowing zoom affecting the entire content area including the Reader View controls.

If the desired behaviour is that Ctrl+mousewheel should change the font size (i.e. the same custom behaviour as today) while touchpad pinch gestures should trigger non-reflowing zoom, we would need a platform change that allows distinguishing between the two in JS code. This is possible to do (and it's easier to do for the Reader View implementation's JS code than it would be for general web content, since the former has access to privileged APIs).

Comment 5

[Will]

Thank you so much for looking at this! Obviously I can't speak for others and ultimately it's up to Firefox devs but this reflow type of zoom in reader view when you pinch zoom on the touchpad feels really wrong and bad to me, it's just not what I expect. And I just can't imagine anyone likes it this way. Another reason I think this should change is because the way reflow zoom works in reader view, images don't increase in size, only the text does, so when you want to zoom in on an image you have to leave reader view or if you have a touchscreen, zoom in via touchscreen so you can make the image bigger.

Comment 6

[Botond Ballo [:botond]]

(In reply to Will from comment #5)

Another reason I think this should change is because the way reflow zoom works in reader view, images don't increase in size, only the text does,

Thanks for pointing that out, I overlooked that -- this is an additional difference between Reader View's custom behaviour, and the browser's default reflowing-zoom (which would increase the size of images as well).

Comment 7

[Will]

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

(In reply to Will from comment #5)

Another reason I think this should change is because the way reflow zoom works in reader view, images don't increase in size, only the text does,

Thanks for pointing that out, I overlooked that -- this is an additional difference between Reader View's custom behaviour, and the browser's default reflowing-zoom (which would increase the size of images as well).

Yes, for me it's a very minor inconvenience because my laptop has a touchscreen but for people that don't have a touchscreen, if they want to zoom in on an image they'll be forced to leave reader view (unless that can be changed?)

Comment 8

[:Gijs (he/him)]

(In reply to Will from comment #5)

this reflow type of zoom in reader view when you pinch zoom on the touchpad feels really wrong and bad to me, it's just not what I expect. And I just can't imagine anyone likes it this way.

It also doesn't make much sense for page zoom to change browser UI, which is why we made the change. And it is confusing to have both in-page specific controls for text size etc. (which effectively zoom most of the page, "just" not the images), and then also have "full page zoom" that shows a zoom indicator in the address bar and hamburger menu and so on, and would be stored across different reader mode pages. 🤷

Honestly I'm not sure what the "right" solution here looks like - it feels like it would need a wholesale rethink by UX on how reader view (and perhaps PDFs) and its text size and reflow controls should integrate with the various types of zoom we support.

A spot-fix would be to make the touchpad pinch zoom thing not be intercepted, but based on comment 4 this isn't trivial either (would need platform support). This also still wouldn't allow zooming images to people without the touchpad (as in, that's functionality loss from reader mode intercepting page zoom at all), so I don't super love that, either.

Comment 9

[Will]

PDF's do scale style zoom when you pinch zoom on the touchpad, it's great (though it's quite janky and stuttery compared to regular webpages, at least on Windows).

Firefox users should have a say in this reader view pinch zoom situation, maybe ask people on Firefox socials and Mozilla Connect which type of zoom they would prefer when pinch zooming via touchpad. I will say this though, I remember in one of the bugs where people were complaining about Firefox's lack of scale style pinch zoom for the touchpad, someone from Mozilla initially rejected it and one of the reasons they gave was that having a reflow zoom in addition to a scale style pinch zoom would be confusing to users... Obviously that concern didn't age well. Scale style zooming for touchpad pinch zooms and touchscreen pinch zooms are just a fact of life.

Comment 10

[Botond Ballo [:botond]]

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

If the desired behaviour is that Ctrl+mousewheel should change the font size (i.e. the same custom behaviour as today) while touchpad pinch gestures should trigger non-reflowing zoom, we would need a platform change that allows distinguishing between the two in JS code.

This has come up before as something that web content would like to be able to distinguish between as well; I filed bug 1992883 to track proposing a standard mechanism by which it could do so.

Note that if we decide to go with this approach for Reader View, that doesn't need to blocked on the standardized mechanism (we can give Reader View, as Firefox-specific JS code, an internal API to do the same thing).