The mouse wheel's settings are superfluous, nicely as the preferences panel may have been implemented. These settings are a perfect example of inappropriate delegation of design, offloading it from the interface designer to the user. These settings should be decided once by the designer, as other similar mechanisms are. (References: The behavior of modifier keys with: cursor keys in text, following links, drag-and-drop operations.) I might be convinced that this configurability were not utterly useless if there were more outputs (behaviors) than inputs (modifier key combinations) to map them onto. If that were the case, users would need a way to assert which actions were most useful to them. However, it is far from being the case: MODIFIER KEYS PLATFORM ACTIONS SINGULAR IN COMBINATION Windows 3 4 8 Macintosh 3 5 16 Unix 3 5 16 By analogy to the familiar behavior of cursor keys in text, I propose this: MODIFIERS BEHAVIOR UP/DOWN -> WHEEL none by line -> by line shift extend selection -> by line (Macintosh) option by paragraph -> by screenful command beginning/end -> beginning/end control undefined -> history (Windows) control by paragraph -> by screenful alt undefined -> history Notes: - Shift-up and -down extends the selection by one line on both operating systems. That behavior is meaningless when scrolling. To maintain the analogy, however, defining a new behavior for shift-wheel should be avoided if possible, and it is indeed possible in this case. - Command-up and -down on the Macintosh scroll to the beginning and end of a document. There is no reason not to extend the analogy fully and support this behavior with the scroll wheel. - The modifier keys used for navigating the history with the wheel were selected by using the modifier keys whose behavior is undefined when editing text. (I haven't proposed a mapping for Unix because I don't use X enough to be familiar with what users there would expect. Their expectation is probably "absolutely anything" and the Windows behavior would be acceptable, leaving the behavior of meta+wheel undefined.)

To sum up, "yeah, it's nice that it's configurable. But does everything need to be configurable, what about Shift-Reload?"

Getting rid of the prefs panel is perhaps an option, I'd need to think about it some more. I'm also planning to add the option to have mousewheel movement trigger the "Enlarge/Reduce text size" command on the View menu, as suggested in another bug. IE implements this with ctrl-mousewheel. As for the platform-specific mappings you've suggested, that could be implemented fairly easily using the existing prefs architecture (just moving the mousewheel preferences from all.js to winpref.js/macprefs.js/unix.js). If you'd like to come up with some patches to the pref files to implement good defaults, I'd be more than willing to check that in. I don't think we lose anything by having this configurable in the preferences.js file. I'm not sure, though, that there necessarily has to be a logical extension from the up/down keys.

I should also note that mousewheel is completely unsupported on Mac right now (see bug 7347), so we should probably hide those preferences entirely on that platform.

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (mpt@mailandnews.com). Matthew Thomas is now the QA owner for the User Interface: Design Feedback component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser should continue be QA assigned to elig@netscape.com.)

There *might* be a case for retaining this prefs panel, if it was turned into a general `scrolling' panel which allowed you to specify scrolling/non-scrolling behaviors for not only a mousewheel, but also a middle mouse button. Since the middle mouse button is used for various scrolling purposes by many different utilities (which are not part of the OS, and so can't really be tracked) for any native scrollable region, such a prefs panel might be necessary in order to get Mozilla behaving consistently with the rest of the OS on a given system.

adding myself to the cc list, as I quickly hacked up the initial ui for these prefs. we can use platform specific overlays, so that on mac, unix and windows, the pref ui is makes sense on each platform. for examples of this, see the OK-Cancel dialog overlay.

I have to agree that in the current incarnation, the mouse wheel settings seem a bit superfluous. A standard "how many lines would you like to scroll per click?" would suffice. Reassigning to German for comment.

who is implementing it? I don't think it has anything to do with German ( or he just kept silent :-). I rememeberd someone else was writing the UI. Eli, can you remember who is responsible for it? set to later M18.

I'll take the bug, although I haven't yet decided what to do with it.

Bug 4077 is somewhat related.. it talks about how far the up/down keys should scroll.

This level of configurability is the sort of feature that mozillians would probably love, but is just an unnecessary and unwanted complication for the huddled masses who just want to scroll. I'd hope that companies (e.g. Netscape) producing derivative works for end-users would have time to remove it, or at least tone it down considerably, in their releases.

I could do a pref to hide it from the prefs page easily enough. I'd like to get good default behaviors set up first though. Here's my current thinking: No modifier -- standard 3-line scroll Alt + wheel -- back/forward Control + wheel -- font size enlarge/reduce (this idea comes from IE) Shift + wheel -- ?? (we could choose from full-page scroll or single-line scroll) Adding a binding to enlarge/reduce font size is on my to-do list and should be pretty easy since Erik has done the hard part already. I would also go ahead and add the "hide mousewheel panel" pref to the mac-specific pref defaults in Moz, because the scrolling is unimplemented. As far as Netscape using that as a global default, it doesn't much matter to me either way. Would that be acceptable to everyone?

*cough* *cough* ... *retch* The whole point, Brian, is to *reduce* the amount of unnecessary configurability -- not to increase it. And this isn't about whether Netscape includes such prefs, it's about whether Mozilla does. Gordon doesn't think it's at all necessary, and neither do I. So no, please don't include in a pref for including the prefs. And, for that matter, don't include a pref for including the pref for including the prefs. As for your suggested modifier key assignments, I think they are a bit better than Gordon's -- but they need a bit of tweaking to work on Mac as well as they do on Windows and Unix. So here's a minor revision of your proposal: Windows/Unix Mac OS Effect --------------------------------------------------------------------------------- scroll scroll line up/down - reason: expected basic behavior of scroll wheel Shift+scroll Shift+scroll line up/down - reason: scroll wheel may be being used to find a point to extend a selection to, in which case Shift will be down and I won't want that to affect the scrolling Ctrl+scroll Cmd+scroll reduce/enlarge text - reason: consistent with usual use of Ctrl/Cmd as `action' modifiers Alt+scroll Ctrl+scroll open menu popup for navigating through window history (with large target area for staying right where you are) - reason: matches suggested keyboard modifiers of Left/Right for back/forward navigation on each platform Ctrl+Alt+scroll Option+scroll scroll to beginning/end of document - reason: less common action gets whichever modifier is left over.

I need a better idea what you mean by opening a menu popup for navigating history. Personally, I think one click of the mouse wheel should accomplish one action... not lead to something that requires additional input to complete the action. I hadn't planned on doing anything with multiple modifier keys, nor is scrolling dirctly to the top or bottom of the document implemented yet... are you sure this would actually be useful? Is it something a user would be likely to try?

Hi folks, just been chatting to bryner, and here's another point, that may or may not influence this: Some widgets may want to do their own behaviour for the wheelmouse. So having a user supplied default is nice, but in the end, the behaviour on input should depend on the skin. Or even the widget. If getting mousewheel down to XBL doesn't work (bryner thought no), should this be an extra bug? To get your minds going, a 3D widget could want to use the wheel to move the cursor in z-direction. Perhaps bringing this in a broader context eases the decision. I doubt it ;-) Axel

Ok, so basically people are complaining about a portion of the preference dialog. At some point this bug should be moved to Preferences. A few things to consider: What are logical events based on the wheel? . Scroll (Page) . Zoom (Page) -- http://www.microsoft.com/products/hardware/mouse/intellimouse/sdk/SDKWORDLIST.h tm#defZoom . Base Font (Page/All Pages?) . History (Window) . Windows (Application) -- Wouldn't it be nice if you could use the wheel to glide from one Mozilla window to the next [in sequence]? . Auto Scroll (Yes this is not exactly the wheel, it's an abuse of the wheel button) -- http://www.microsoft.com/products/hardware/mouse/intellimouse/sdk/SDKWORDLIST.h tm#defAutoScroll . Data zoom (imo, being able to change the level of detail from <h1..h7+p> to <h1..h2> or something like that) -- according to microsoft: http://www.microsoft.com/products/hardware/mouse/intellimouse/sdk/SDKWORDLIST.h tm#defdatazoom . Pan -- http://www.microsoft.com/products/hardware/mouse/intellimouse/sdk/SDKWORDLIST.h tm#defpanning Wow. that's 8 different actions. And I might have missed a few... Oh well... it might also be cool to be able to scroll from Anchor <a name> to Anchor. [9]. Anchor based navigation. ---- Changed Summary [Wheel Settings Unnecessary] Various reminders... Windows allows the user to specify os defaults for standard scrolling: N lines, or Screen [default 3 lines], mine is set for 5 lines. What is a line? Maybe it's a certain number of pixels picas points inches centimeters twips. Maybe it's just characters. If you want to scroll a single line there is a down arrow key and the down arrow on the scroll bar. Personally I'd prefer Shift to do full window scrolling [Page is already defined in other contexts] In windows you can <click(release)> move mouse elsewhere <shift>-<click(release)> and you now have a selection. Holding shift is not required.

Brian: the popup for history would be like the popup you get when you press Alt+Tab in Windows. It would answer the question `how much do you need to scroll to go back one page, and how much for two pages?' > Personally, I think one click of the mouse wheel should accomplish one > action... I thought we were talking about the mouse wheel, not the middle mouse button. That these are activated using the same bit of plastic on many mice is not really relevant. IIRC, the middle mouse button is being used for the Paste command. > I hadn't planned on doing anything with multiple modifier keys, nor is > scrolling dirctly to the top or bottom of the document implemented yet... are > you sure this would actually be useful? Is it something a user would be likely > to try? I have no idea, I just included it because there was a spare modifier key available on Mac OS, because the user would probably be expecting that modifier key to do *something*, and because I have a hunch that people would be useful. > Some widgets may want to do their own behaviour for the wheelmouse. So having a > user supplied default is nice, but in the end, the behaviour on input should > depend on the skin. Or even the widget. Sure. That's fine. It's up to the widget to sort that out (and if that's not possible, then yes it's a bug). The issue here is the default actions for the mousewheel in normal scrolling situations -- Navigator and Composer documents, Messenger panes, etc. timeless@bemail.org: * Zoom is not currently implemented in Mozilla, and chances are most users would find text size more useful than raw zoom (except in non-text documents, but that's a problem for another day). * Switching between windows: no, that wouldn't be useful. The content in a different window is almost always different from that in the current window; and the point of having mousewheel settings in the first place is to allow for changing of settings while keeping the cursor's position in the *current* content relatively static. * Auto-scroll: that's a job for the wheel button (aka the middle mouse button), not the mousewheel itself. * Data zoom: not relevant for the current generation of HTML and XML documents, and of dubious relevance in the future. * `Windows allows the user to specify os defaults for standard scrolling': good, well use the OS defaults. There's no sense in duplicating them in Mozilla. * `Personally I'd prefer Shift to do full window scrolling [Page is already defined in other contexts] In windows you can <click(release)> move mouse elsewhere <shift>-<click(release)> and you now have a selection. Holding shift is not required.' Yes, I know, but when people go to extend a selection, many will instinctively start holding down Shift *before* they start looking for the point to extend the selection to. Which is why Shift+scroll should do the same thing as plain scroll.

Gargh. `people would be useful' --> `people would find scrolling to the beginning/end of the document useful'. (Sorry for the spam ...)

Sorry, by "one click of the mousewheel" I meant one movement (rotation) of the wheel. Text zoom *is* implemented currently (View/Enlarge text size), and that's what I was going to hook up for control + mousewheel. We do use the OS default for number of lines to scroll on Windows. From a practical point of view, we don't need to worry about the fact that Mac has an extra modifer key out there, because I don't see Mac mousewheel scrolling implemented in the 5.0 timeframe (see bug 7347 for details), and we don't support the Meta key on unix even if the system has one. So, I will implement the text zoom, set that as control-mousewheel, then look at removing the prefs panel (I should note that regardless, it will be possible to override the behavior through manual editing of the prefs file -- that's already done and I see no compelling reason to hardcode it instead).

Moving all my bugs to this email.

See also bug 45647, discussing whether it's a good idea to have the mousewheel changing font size.

Clearing target milestone.

->Future to get off NS6 radar.

general architecture issue, setting to mozilla 1.0. if we decide to change this, it won't be hard to do.

--> biesi, CC bryner. Just remove the panel; if any of the defaults are wrong, they can be dealt with in other bugs (e.g. bug 64908).

In addition to applying this patch, I will cvs remove content/pref-mousewheel.xul and locale/en-US/pref-mousewheel.dtd when checking in. This patch also gives two pref panels IDs, I need that for other bugs and figured I can do it in this patch while I'm touching this file.

blake or ben, could you sr this patch?

sorry for beeing a little late for this discussion, but is necessary to remove the panel? I think it would be better to just hide it for now. So that you wont be able to navigate to it. Later it could be added in something like 'All advanced preferences' dialog which could be started using another menu item, not the standard 'Edit | Preferences', so that simple users do not get confused. I think this is a kind of solution that could satisfy everyone. I personally liked very much the ability to remove my Ctrl+Scroll binding from Increase-Decrease fonts.

I have learned that UI patches are not wanted in this project. reassigning to default owner.

Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com

(Filter "spam" on 'prefs-nobody-20080612'.)

Don't think that removing this Preferences section will be good for SeaMonkey, propose WONTFIX