37139 - mouse wheel capabilities and how should it be configured

Status: RESOLVED WONTFIX

(SeaMonkey :: Preferences, defect)

Description

[Gordon Henriksen]

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

Comment 1

[Joseph Elwell]

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

Comment 2

[old account]

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.

Comment 3

[old account]

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.

Comment 4

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

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 [e-mail].)

Comment 5

[Matthew T (active 1999-2002)]

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.

Comment 6

[(not reading, please use [e-mail] instead)]

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.

Comment 7

[Brendan Donohoe]

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.

Comment 8

[shuang (gone)]

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.

Comment 9

[old account]

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

Comment 10

[Jesse Ruderman]

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

Comment 11

[Peter Trudelle]

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.

Comment 12

[old account]

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?

Comment 13

[Matthew T (active 1999-2002)]

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

Comment 14

[old account]

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?

Comment 15

[Axel Hecht]

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

Comment 16

[timeless]

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.

Comment 17

[Matthew T (active 1999-2002)]

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.

[e-mail]:

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

Comment 18

[Matthew T (active 1999-2002)]

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

Comment 19

[old account]

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

Comment 20

[Brian Ryner (not reading)]

Moving all my bugs to this email.

Comment 21

[Matthew T (active 1999-2002)]

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

Comment 22

[Brian Ryner (not reading)]

Clearing target milestone.

Comment 23

[Peter Trudelle]

->Future to get off NS6 radar.

Comment 24

[Brian Ryner (not reading)]

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

Comment 25

[Matthew T (active 1999-2002)]

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

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

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.

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

blake or ben, could you sr this patch?

Comment 28

[Mihail Daskalov]

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.

Comment 29

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 30

[Ben Goodger (use ben at mozilla dot org for email)]

Mass reassign of my non-Firefox bugs to [e-mail]

Comment 31

[Serge Gautherie (:sgautherie)]

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

Comment 32

[Phoenix]

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