Closed Bug 45647 Opened 24 years ago Closed 24 years ago

Ctrl + Mousewheel to increase font size - bad combo

Categories

(SeaMonkey :: General, defect, P4)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: neil, Assigned: bryner)

References

Details

(Whiteboard: [nsbeta3+]) 

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.
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
changing default assignees to the owners for this component.
Assignee: putterman → bdonohoe
QA Contact: lchiang → mpt
Status: NEW → ASSIGNED
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
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.
HTML listboxes also allow multiple selection ...
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
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
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
Beta 3 is fine.  It might get in the way a little in beta 2, but it won't do any damage.
nsbeta3+
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
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.
> 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.

P4
Priority: P3 → P4
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.
Depends on: 37940
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.

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.
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).

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).

Turned this off by default.  Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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 ;)

worksforme too
verified: 
2000-10-23-09-MN6 : win32 
2000-10-23-13-MN6 : linux
Status: RESOLVED → VERIFIED
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.
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?
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.