314250 - Scroll+keyboard mapping which resizes fonts uses bad key mapping

Status: RESOLVED FIXED

(Firefox :: General, enhancement)

Description

[thul]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

On the latest beta of Firefox 1.5 (beta 2), I've found that if I scroll using my scrolling trackpad wshile holding down the Command key, the web page fonts will resize.  This seems like a good idea on paper, but is quite annoying as a default setting when I'm opening multiple tabs in the background (by holding down Command while clicking the links).  This results in my inadvertently changing the font size many times, and is quite annoying.  Could this be remapped to a different keystroke + scroll combination by default which doesn't pose this type of problem?
It seems like users of tabbed browsing would find this annoying.

Reproducible: Always

Comment 1

[Mark Mentovai]

We went with command because that's what Opera uses.  I see that command might be bad for users accustomed to leaving the command key depressed so that links can open in new tabs.  As a workaround, you can make the following pref changes:

mousewheel.withmetakey.action = 0
mousewheel.withmetakey.sysnumlines = true

Mano, Beltzner, I think that this is probably a fairly common user behavior.  This isn't the first report that I've seen, and it's even tripped me up once or twice.  I'm inclined to move text size to the option key, or to the control key with history on option.  I don't care much about line-at-a-time scrolling (on option now) - I know it's documented, but cvs logs seem to indicate that it was only introduced by accident.

Note also that we're not married to Opera's precedent - these keys were introduced a only a few weeks ago, and we coudln't use Opera's shift mapping for history because shift-scroll isn't available on all mice on the Mac.  If we can do a better job by picking other keys, then we should.

Comment 2

[Asaf Romano (gone)]

I'm not married to Cmd+Wheel for textsize either. However, I don't see how switching between the modifiers would help - opt+click on a link saves it, ctrl+click opens its context menu.

Comment 3

[Mark Mentovai]

I think that by far, the most likely modifier that users are likely to have depressed is command.  The only complaints I've heard about this feature have been about text size, there hasn't been groaning about history.

Comment 4

[Mark Mentovai]

Attachment: Puts history on option, uses XP key for text size

Control is the cross-platform modifier for text size.  This moves text size from command/meta to that key on the Mac, and puts history on option/alt.  As discussed, the cross-platform history modifier, shift, can't be reliably used on the Mac.

Comment 5

[Ulrik Sverdrup]

*** Bug 314287 has been marked as a duplicate of this bug. ***

Comment 6

[Ulrik Sverdrup]

The default key should be changed to option (or something else). This issue is mentioned on the forums, and I myself experience it a lot.

With the command key, sure it's discoverable, but I get lags from inadvertedly resizing pages _all the time_. 

See dup bug 314287 for more comments.

Comment 7

[Mark Mentovai]

Attachment: Puts history on option, uses XP key for text size

Comment 8

[Asaf Romano (gone)]

Comment on attachment 201308 [details] [diff] [review]
Puts history on option, uses XP key for text size

This late in the game, you'll have to update the help files too.

Comment 9

[Asaf Romano (gone)]

Oh, and we should consider using meta+wheel for line-by-line scrolling, it doesn't hurt as much as text-size changes, I think.

Comment 10

[Asaf Romano (gone)]

(Also, fwiw, control is used for both actions on windows/gtk).

Comment 11

[Mark Mentovai]

Attachment: With en-US doc change

Comment 12

[Asaf Romano (gone)]

Comment on attachment 201488 [details] [diff] [review]
With en-US doc change

r=mano code-wise. passing to mconnor for UE-approval (esp. on the line-by-line gesture removal).

Comment 13

[Mark Mentovai]

I opted to use control-wheel for text size because it's the cross-platform modifier for that purpose.  I don't really see a fantastic compelling reason to support line-at-a-time on the command key: it hurts less than text size, but it's still perceptible.

Comment 14

[Mike Connor [:mconnor]]

Comment on attachment 201488 [details] [diff] [review]
With en-US doc change

I'm not really sure about what's truly "right" on Mac, passing off to beltzner.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 201488 [details] [diff] [review]
With en-US doc change

There is no "right way" on Mac. We're using cmd instead of ctrl for open links since that's the closest thing to platform native that there is. There's no platform native control for resizing text, so we can pretty much make it up as we go. Ctrl is as good as any other key.

A couple of notes: First, I'm not quite sure why Mac users are running into the reporter's issue more than PC users. Second, I'm not sure why the line-by-line was removed entirely. Yes, it's a noticable difference when you hold down cmd, but it's hardly destructive, causes zero lag, and the user is, after all, holding down a modifier key. I simply refuse to beleive that users keep their pinky pressing the cmd key down all day long. :)

Please add the line-by-line back as a meta-key modification.

Comment 16

[Mark Mentovai]

Attachment: Use command-wheel for line-by-line

I don't agree, but OK.

Oh, and on a real Mac, you hold command with your thumb, not your pinky.  Maybe that's where the difference is.

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 202554 [details] [diff] [review]
Use command-wheel for line-by-line

Thanks, Mark.

Comment 18

[Mark Mentovai]

Attachment: Dump all of the v-scroll prefs into firefox.js

Mano said he'd like to see all of the scrolling prefs in firefox.js, including those that are inherited from all.js.  I'm not bringing the horizontal scrolling prefs in because those are all left at their all.js values and I don't want to duplicate the HORIZSCROLL_AVAILABLE conditionals from all.js.

Comment 19

[Asaf Romano (gone)]

Comment on attachment 202700 [details] [diff] [review]
Dump all of the v-scroll prefs into firefox.js

r=mano.

Comment 20

[Mark Mentovai]

Checked in on trunk.

Comment 21

[Mark Mentovai]

Moving my stability bugs to blocking1.8.0.1?

Comment 22

[Steffen Wilberg]

Comment on attachment 202700 [details] [diff] [review]
Dump all of the v-scroll prefs into firefox.js

You should request approval1.8.1 if you want this to make Firefox 2.

Comment 23

[Mark Mentovai]

Comment on attachment 202700 [details] [diff] [review]
Dump all of the v-scroll prefs into firefox.js

This one is a regression in 1.5 relative to 1.0.  In 1.0, command-scrollwheel didn't do anything.  In 1.5, it changes the text size.  It seems that we picked a bad key for this function, as many Mac users have a tendency to keep the command key depressed while casually browsing and scrolling, to get links to open in new tabs.

There is l10n impact here, although it's limited to changing key entities.

Comment 24

[Benjamin Smedberg]

Comment on attachment 202700 [details] [diff] [review]
Dump all of the v-scroll prefs into firefox.js

mconnor, does making the behavior change for FF2 make sense?

Comment 25

[Mark Mentovai]

Checked in on MOZILLA_1_8_BRANCH for 1.8.1.

Comment 26

[Mark Mentovai]

Note bug 346084

Comment 27

[Martin Reurings]

Sorry to chime in on this so late, I'm obviously a different type of mac user and was quite puzzled when testing a new FF build using a clean profile. I use the cmd+scrollwheel a lot for font resizing since I'm of a meaning that the user preference for font-size should be important to websites and many websites like to over-rule my preference with something silly like 0.8em.
Now I could even live with a change to ctrl-scroll but having the rest of the font-sizing keymappings on meta-'0', meta-'+' and meta-'-' is extremely counter-intuitive. So I'm not sure if this is the right place to report this info, but I would vote for moving those three mappings over to ctrl as well, that way when people, like me, are resizing the font we won't have to alternate between two different modifiers.

Comment 28

[Jake Olefsky]

*** Bug 357035 has been marked as a duplicate of this bug. ***