Ctrl + Mousewheel to increase font size - bad combo

VERIFIED FIXED in M18

Status

SeaMonkey
General
P4
minor
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Neil Marshall, Assigned: Brian Ryner (not reading))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+])

(Reporter)

Description

18 years ago
To scroll the messages you use the mouse wheel.
To select multiple messages, you hold control and select the items in the list.
To increase the font size you hold ctrl while moving the mouse wheel.

This is a bad combonation when scrolling through messages and selecting specific
ones.  Some times you inadvertantly hold down the control when you use the mouse
wheel and the interfaces font size increases/decreases on you.

Comment 1

18 years ago
Yea, that could be a problem, but the ctrl+mousewheel to increase font size 
exist in the main browser also, so this really shouldn't be mailnews, even 
though that it where the situation might be most evident. Marking as New.
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → User Interface: Design Feedback
Ever confirmed: true
OS: Windows NT → All
Product: MailNews → Browser
Hardware: PC → All

Comment 2

18 years ago
changing default assignees to the owners for this component.
Assignee: putterman → bdonohoe
QA Contact: lchiang → mpt

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 3

18 years ago
I don't think changing the font size should be a job for the mousewheel at all. 
In my limited experience using IE on Windows, I've accidentally changed the font 
size in this way several times.

* Mousewheel issue: CCing bryner.
* I don't have a mousewheel: QAing Sarah.
QA Contact: mpt → sairuh
(Assignee)

Comment 4

18 years ago
Well, we've had had arguments both for and against this.  This particular
situation might be able to be avoided if we just disable the ctrl-mousewheel
behavior in trees, since that's the only time you would be doing multiple
selection.

Comment 5

18 years ago
HTML listboxes also allow multiple selection ...
(Assignee)

Comment 6

18 years ago
Good point.  And I don't want to do too much special casing for certain controls
since people might be coming up with their own widgets via xbl.  I'll need to do
some more thinking about this.
qa over to janc, who works on da mousewheel.
QA Contact: sairuh → janc

Comment 8

18 years ago
There should already be a keyboard shortcut to handle font size changes.  Though I agree that the mouse wheel is a useful tool and a handy place to hang additional shortcuts, this shortcut isn't the best use of the space.  Since changing the font size shouldn't be a constantly used item (like, say, scrolling and multiple selection), I recommend removing the shortcut entirely.  Just keep the keyboard equivalent and the menu item (which has its own set of issues in bug#37940).

Reassigning to bryner (reassign if you're not the right person to make the change)
Assignee: bdonohoe → bryner
Status: ASSIGNED → NEW
(Assignee)

Comment 9

18 years ago
Sure, this can be done just by changing the default preferences to make
ctrl-mousewheel work the same as normal mousewheel.  I'm tentatively nominating
this for beta3, let me know if you think I should push for beta2.
Status: NEW → ASSIGNED
Keywords: nsbeta3

Comment 10

18 years ago
Beta 3 is fine.  It might get in the way a little in beta 2, but it won't do any damage.

Comment 11

18 years ago
nsbeta3+
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18

Comment 12

18 years ago
Arg, this is used in other apps. I think it's a good idea to have 
ctrl+mousewheel.

A few notes:
a) Ctrl and scrolling don't make sense.  Control is used to modify a selection. 
 If you're scrolling then what do you expect control to do?
b) Just because some people use the keyboard doesn't mean they should be 
forced to, this can be a common activity. And It isn't unreasonable to want 
fluid font size changes.

I agree that trees shouldn't change fonts.  How about special casing the other 
way? Ctrl+wheel should only behave as described while gecko [html/css 
rendering] is active.  If you're typing in a form then you wouldn't want this 
behavior and it wouldn't be logical.  It should be easy enough to have only 
gecko listen for this.  If some other XBL widget wants to have some behavior 
then it should be possible for that XBL to be able to listen for it.

Comment 13

18 years ago
> a) Ctrl and scrolling don't make sense.  Control is used to modify a selection.
> If you're scrolling then what do you expect control to do?

Nothing. (Read the original bug report.) And if you've done an advanced Bugzilla 
query using IE for Windows (like I do when at work), you'll know why -- the font 
size changes all over the place as you're trying to select various Status and 
Resolution fields.

> b) Just because some people use the keyboard doesn't mean they should be
> forced to, this can be a common activity. And It isn't unreasonable to want
> fluid font size changes.

I think bug 37940 is enough, really. We could probably have Smaller and Larger 
buttons on the toolbar too, if the toolbar wasn't so weirdly designed (i.e. if it 
had more room for other buttons). And I don't think we should encumber the 
scrollwheel interface, just because the toolbar happens to have a bad interface 
right now.

Comment 14

18 years ago
P4
Priority: P3 → P4

Comment 15

18 years ago
Please don't take away control-mousewheel to change font size until there's a
key binding for increase/decrease!  There are still a lot of bugs making many
pages unreadable on Unix without increase/decrease, and I use control-mousewheel
all the time for this purpose.  If there were a key binding, I'd probably use
that instead and wouldn't miss control-mousewheel.
(Assignee)

Updated

18 years ago
Depends on: 37940
(Assignee)

Comment 16

18 years ago
Going by the logic of eliminating mousewheel shortcuts where keyboard shortcuts
exist, we should also get rid of the alt+mousewheel binding for back and forward
(although this was specifically requested by some people, as was the font size
shortcut).

What do you all think?  I'm not all that opposed to a one-shortcut-per-action
approach.

Comment 17

18 years ago
Just as I dislike killing access points to bookmarks, I dislike removing access 
points to logical functionality.  The wheel features should be allowed to work. 
Food for thought: not all machines have mice, so everything should be keyboard 
accessible. But we still support left and right clicking.  Not everyone has 
wheels, but we still support back and forward (2 key combos, 2 menus, one 
button set) and wheel based.  We add stuff to the wheel to make it useful not 
to remove it from other places nor to later remove it from the wheel.

Comment 18

18 years ago
Brian, we're not `eliminating mousewheel shortcuts where keyboard shortcuts
exist', we're eliminating mousewheel shortcuts where they interfere with other 
established uses of the mouse (in this case, multiple selection).
(Assignee)

Comment 19

18 years ago
you know, I really think I might make this binding a non-default even though we 
don't have a keyboard shortcut yet.  It doesn't mesh well with the redesigned 
font size menu (i.e. it should move from small -> large on the list, rather than 
changing the text size by some arbitrary amount).
(Assignee)

Comment 20

18 years ago
Turned this off by default.  Marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 21

18 years ago
Just wanted to say thanks for just having the preference off by default, instead
of getting rid of it. I find the alt+wheel for forward and back one of the most
useful things in mozilla, and the resizing is kind of nice. Easier even then the
keyboard command to get to...

Frankly, bugzilla is probably the first time in 5 years of surfing that I've
seen text boxes where you have the option of control-clicking to select multiple
items. I certainly don't see it interfering in normal surfing at all...

As for fitting it into the Text Size menu, the two things that come to mind are
either modify the mouse zooming to correspond to the intervals in the menu, or
(and seems good to me), keep it the same as it is now, but put the current zoom
amount into the label of the Other box. This way you could zoom with the mouse
and then see where you are in relation to the percents for future reference...

If people don't want to use the features, that is fine with me, but I really
like having the option there...

One last thing... I think it'd be really nice if it said on the status bar what
the percentange of zooming was while you used the mouse-wheel. That'd eliminate
the problem someone mentioned of not knowing when you've gotten back to normal.

Maybe I'm pushing my luck since it almost got eliminated altogether, but oh
well...worth a shot ;)

Comment 22

18 years ago
worksforme too
verified: 
2000-10-23-09-MN6 : win32 
2000-10-23-13-MN6 : linux
 
Status: RESOLVED → VERIFIED

Comment 23

17 years ago
What happened, I thought the mousewheel support was to be left in. On the latest
nightly 20010117) it's gone.

I too think this is a very useful feature; and having the current zoom level
displayed in the status bar is an excellent idea.

Comment 24

17 years ago
do i need to delete my current prefs.js to see the pref setting for this, or
does a pref NOT exist to turn this feature on/off?

Updated

15 years ago
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.