1640271 - Cmd/Ctrl + touchpad scroll zooms page text in Firefox, but not Chrome, Edge, IE11, or Safari

Status: RESOLVED DUPLICATE of bug 1781960

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

Description

[Chris Peterson [:cpeterson]]

Scrolling the touchpad while holding down the Cmd key on macOS (or Ctrl key on Windows) zooms the page in Firefox.

STR: On news sites, I like to scroll the page and Cmd+click links to open a bunch of articles in background tabs. I will often inadvertently or lazily hold down the Cmd key too long after clicking and then scroll, which zooms the page and loses my reading position on the page.

This is a personal annoyance for me that I can work around, but I expect some users might get in this zoomed page state and not know how to escape. Changing the mousewheel.with_meta.action pref from 3 to 1 fixes this problem on macOS. That is the first pref change I make when creating a new profile.

Curiously, the mousewheel prefs in all.js have different default values than the mousewheel prefs in firefox.js.

Browser	OS	Cmd + touchpad scroll	Cmd + mousewheel scroll
Firefox 80	macOS	Zooms page	Zooms page
Chrome	macOS	Scrolls page	Scrolls page
Safari	macOS	Scrolls page	Scrolls page

Browser	OS	Ctrl + touchpad scroll	Ctrl + mousewheel scroll
Firefox 80	Windows 10	Zooms page	Zooms page
Chrome	Windows 10	Scrolls page	Zooms page
Chromium Edge	Windows 10	Scrolls page	(I haven't tested, but it presumably matches Chrome.)
IE11	Windows 10	Scrolls page	(I haven't tested, but it presumably zooms because I read in Microsoft help forums that Trident Edge zooms.)

Comment 1

[Chris Peterson [:cpeterson]]

Since this touchpad zoom behavior has been the Firefox default for at least 13 years (bug 389628?), perhaps it should be grandfathered in as the expected behavior.

OTOH, the grandfathering argument didn't prevent changing the macOS Firefox address bar's "Add www and .com to address bar string and Go" keyboard shortcut from Cmd+Enter to Ctrl+Enter (bug 237027 in Firefox 64) after Cmd+Enter had been the default behavior for a similarly long time.

Comment 2

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Chris Peterson [:cpeterson]]

I think we should reconsider this default. I'm sure many users accidentally zoom the page and don't know how to unzoom the page, effectively breaking the user's web browsing experience.

On macOS, I think the mousewheel.with_meta.action prefs default value should be changed from 3 to 1.

Comment 4

[Stephen A Pohl [:spohl]]

Moving to Firefox > General to give this more visibility as this is presumably a matter of changing a default value for mousewheel.with_meta.action, rather than a change at the widget level.

Comment 5

[Drew Willcoxon :adw]

Sounds like this needs a Product decision about changing the default. Not sure who that would be. Ray, do you happen to know who in Product might be able to own this?

Comment 6

[Ray Fambro]

My apologies for the delay here. I'm currently doing some digging to get an understanding of the historical context related to our default behavior for this. As of now, the priority is set appropriately...as this isn't an immediate issue for us to address atm.

Comment 7

[Ray Fambro]

Marking as won't fix for now. Haven't seen a ton of duplicate bugs reported for this issue, and I also wouldn't want to break the experience for existing users that have become accustomed to this behavior. Happy to chat about this more at a later time though!

Comment 8

[Chris Peterson [:cpeterson]]

(In reply to Ray Fambro from comment #7)

I also wouldn't want to break the experience for existing users that have become accustomed to this behavior. Happy to chat about this more at a later time though!

Ray, since Firefox's handling of Cmd + touchpad scroll and Cmd + mousewheel scroll (on macOS) and Ctrl + touchpad scroll (on Windows) differs from all other browsers (Chrome, Edge, IE11, and Safari), we could follow other browsers' behavior for new profiles. That would avoid breaking existing Firefox users' experience while also preserving the familiar behavior for new Firefox users switching from other browsers.

What do you think? Some downsides of implementing different behavior in new and legacy profiles: our SUMO documentation will be inconsistent and our automated testing (of new profiles) will test different behavior than existing users will get (though existing Nightly and Beta users would probably find regressions).

Comment 9

[Romain Testard [:RT]]

FWIW I cannot reproduce the following on my Win11 machine, in my case Ctrl + touchpad scroll will scroll while Ctrl + mousewheel scroll will zoom.
My OS settings are reset to default for touchpad:

• Drag 2 fingers to scroll enabled
• Pinch to zoom enabled
• Down motion scrolls up

Could it be that your touchpad settings are custom? Or Win11 could be different.

Comment 10

[Chris Peterson [:cpeterson]]

(In reply to Romain Testard [:RT] from comment #9)

FWIW I cannot reproduce the following on my Win11 machine, in my case Ctrl + touchpad scroll will scroll while Ctrl + mousewheel scroll will zoom.

Interesting. I can no longer reproduce the touchpad zooming on Windows (but I can still reproduce it on macOS).

I bisected Nightly builds to see when this Ctrl + touchpad scroll behavior changed. I landed on this fix range in Nightly 81, which includes bug 1620055 ("Enable desktop zooming"):

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=02be42e5105ba49e93890fdbd9e24c4f55a9251c&tochange=26de281d4c2171a75d4ad19b07fbd62bd7e69c69

I verified that bug's pref flip "fixed" the touchpad behavior on Windows. I don't know if it was an intentional change, but Firefox's behavior now matches other browsers on Windows.

Firefox on macOS is now the outlier and I think it's worth revisiting. We have already (inadvertently?) changed Firefox's behavior on Windows and apparently nobody complained. Now Firefox on macOS behavior matches neither Safari on macOS nor Firefox on Windows. I think this scroll zooming is a user trap and is easy to hit since newer MacBooks have large touchpads.

Browser	OS	Cmd or Ctrl + touchpad scroll	Cmd or Ctrl + mousewheel scroll
Firefox 103	macOS	Zooms page	Zooms page
Chrome	macOS	Scrolls page	Scrolls page
Safari	macOS	Scrolls page	Scrolls page
Firefox 103	Windows 11	Scrolls page	Zooms page
Chrome	Windows 11	Scrolls page	Zooms page
Edge	Windows 11	Scrolls page	Zooms page

Comment 11

[Timothy Nikkel (:tnikkel)]

(In reply to Chris Peterson [:cpeterson] from comment #10)

Firefox on macOS is now the outlier and I think it's worth revisiting. We have already (inadvertently?) changed Firefox's behavior on Windows and apparently nobody complained. Now Firefox on macOS behavior matches neither Safari on macOS nor Firefox on Windows. I think this scroll zooming is a user trap and is easy to hit since newer MacBooks have large touchpads.

Yeah, I agree. We discussed this in apz meetings about a year ago. I don't believe there is a bug on file so I just filed bug 1781960.

Comment 12

[Timothy Nikkel (:tnikkel)]

(In reply to Chris Peterson [:cpeterson] from comment #10)

(In reply to Romain Testard [:RT] from comment #9)

FWIW I cannot reproduce the following on my Win11 machine, in my case Ctrl + touchpad scroll will scroll while Ctrl + mousewheel scroll will zoom.

Interesting. I can no longer reproduce the touchpad zooming on Windows (but I can still reproduce it on macOS).

I bisected Nightly builds to see when this Ctrl + touchpad scroll behavior changed. I landed on this fix range in Nightly 81, which includes bug 1620055 ("Enable desktop zooming"):

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=02be42e5105ba49e93890fdbd9e24c4f55a9251c&tochange=26de281d4c2171a75d4ad19b07fbd62bd7e69c69

I verified that bug's pref flip "fixed" the touchpad behavior on Windows. I don't know if it was an intentional change, but Firefox's behavior now matches other browsers on Windows.

That was not intentional but it makes sense because I believe flipping on deskop zooming also flipped on direct manipulation support on Windows, which means our touchpad pan gestures would go through a different path.

Comment 13

[Ray Fambro]

Thanks for the update here Chris. If MacOS is now the only outlier, I agree that we should likely update the behavior for the sake of consistency.

Comment 14

[Chris Peterson [:cpeterson]]

(In reply to Timothy Nikkel (:tnikkel) from comment #11)

Yeah, I agree. We discussed this in apz meetings about a year ago. I don't believe there is a bug on file so I just filed bug 1781960.

I'll close this bug in favor of your macOS-specific bug 1781960.