Closed Bug 45647 Opened 25 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.