Last Comment Bug 143038 - Horizontal Scrolling with Mouse wheel+ modifier key
: Horizontal Scrolling with Mouse wheel+ modifier key
Status: NEW
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: P2 enhancement with 22 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 171049 196516 218646 241824 248251 258190 272095 277567 953136 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-08 08:59 PDT by Steven Hunter
Modified: 2016-04-22 02:49 PDT (History)
38 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (only tested with gtk) (12.03 KB, patch)
2004-01-29 01:20 PST, hachiro
no flags Details | Diff | Splinter Review
XUL (workaround) (4.06 KB, application/x-xpinstall)
2004-01-31 02:27 PST, hachiro
no flags Details
UI prefs for mousewheel.horizscroll.* prefs (22.19 KB, patch)
2004-10-24 15:34 PDT, Peter Weilbacher
neil: review-
Details | Diff | Splinter Review
backend-only patch (2.30 KB, patch)
2005-06-01 10:56 PDT, Christian Persch (GNOME) (away; not receiving bug mail)
no flags Details | Diff | Splinter Review
Backend and all new Frontend (52.15 KB, patch)
2005-08-25 05:33 PDT, Daniel Höpfl
no flags Details | Diff | Splinter Review
Backend and all new Frontend (V2) (58.31 KB, patch)
2005-09-05 07:04 PDT, Daniel Höpfl
no flags Details | Diff | Splinter Review
Backend and all new Frontend (V3) (58.81 KB, patch)
2006-01-12 14:19 PST, Daniel Höpfl
no flags Details | Diff | Splinter Review
Horizontal Scrolling with Mouse wheel+ modifier key (3.13 KB, patch)
2014-02-03 03:18 PST, Jan Keromnes [:janx]
areinald.bug: review+
Details | Diff | Splinter Review

Description Steven Hunter 2002-05-08 08:59:25 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041711

Under Preferences->Advanced->Mouse Wheel, I'd like to see an option for mouse
wheel + modifier key to scroll the current page horizontally instead of
vertically (when such scrolling is possible).

Reproducible: Always
Steps to Reproduce:
Not currently a feature.
Comment 1 Matthias Versen [:Matti] 2002-05-08 09:22:33 PDT
see also bug 58589
Comment 2 jag (Peter Annema) 2002-05-08 10:14:45 PDT
-> bryner
Comment 3 Skewer 2002-06-23 09:18:14 PDT
Note that the traditional defaults are:

Mouse wheel: Scroll vertically
Ctrl+wheel: Zoom
Shift+wheel: Pan (scroll horizontally)

Most of the programs that don't follow this tradition either pan when the mouse
is hovering over the horizontal scrollbar (bug 71464) or shamefully don't pan at
all.
Comment 4 Matthias Versen [:Matti] 2002-09-26 15:50:26 PDT
*** Bug 171049 has been marked as a duplicate of this bug. ***
Comment 5 Daniel Wang 2003-03-08 23:10:58 PST
*** Bug 196516 has been marked as a duplicate of this bug. ***
Comment 6 Leland Wang 2003-07-24 02:10:19 PDT
I think that the OS should be All instead of just Windows 2000.
Comment 7 Vaclav Dvorak 2003-07-24 04:19:55 PDT
Indeed.
Comment 8 hachiro 2004-01-29 01:20:33 PST
Created attachment 140146 [details] [diff] [review]
patch (only tested with gtk)

Hi.
This patch adds two options `scroll the document by [N] chars.' and `scroll a
page left or a page right.' to mousewheel's pref-panel.

Tha range of integer value of mousewheel.with*key.action is extended to 5.
4=scroll horizontally.
5=scroll page horizontally.

The result makes mousewheel's pref-panel more verbose
but may help single wheel mouse users.
Comment 9 Steven Hunter 2004-01-29 05:30:37 PST
Great! Any chance for a binary patch for Win32? :)
Comment 10 hachiro 2004-01-31 02:27:07 PST
Created attachment 140298 [details]
XUL (workaround)

(In reply to comment #9)
> Great! Any chance for a binary patch for Win32? :)

Thanks.

Though the best way is building Mozilla with patch,
here is yet another implementation by XUL.
This also implements Bug 71464 imperfectly.

This will be XPInstalled as add-on by simply opening it in Mozilla.
Only works with window, frame and message-pane in Mozilla but none of other
widgets like texbox although original patch works with almost every scrollable
widget.

If you want to change modifier key, amount of scroll or direction,
edit mozilla's chrome/whscroll/content/whscrollOverlay.xul manualy.
The value of mousewheel.with[your modifier]key.action must be 0 or 1 when using
as horizontal scroll trigger.

Uninstallation is done manualy delete the directory named `whscroll' and remove
descriptions about whscroll in chrome.rdf and those lines in some
overlayinfo/*/content/*.rdf files in Mozilla's chrome directory.
Comment 11 Bartosz Wucke 2004-05-14 08:05:08 PDT
Existing workaround: Extension of MozGest
http://optimoz.mozdev.org/gestures/index.html
"wheel rocker" - hold the wheel depressed (or middle button) while scrolling
scrolls horizontally. But still I'd like to see this implemented as well.
Comment 12 Peter Weilbacher 2004-10-02 02:00:27 PDT
I fully agree that there should be GUI options to change horizontal mouse wheel
scrolling. But should they not just mirror the ones for vertical scrolling under
Preferences->Advanced->Mouse Wheel and utilizes the currently hidden preferences
mousewheel.horizscroll.with*key.* (that have bad defaults, see bug 231718)?

That would make much more sense to me than introducing new values for the
vertical/normal scrolling prefs.
Comment 13 Peter Weilbacher 2004-10-24 15:34:28 PDT
Created attachment 163247 [details] [diff] [review]
UI prefs for mousewheel.horizscroll.* prefs

OK, this is my first try. I split each tab in the prefs panel Advanced->Mouse
Wheel into two group boxes, the upper for vertical scrolling, the lower for the
horizontal options. I also added a short paragraph to the respective help page.


Seems to work fine here on OS/2 with the current trunk, all changes I make in
the GUI panel are reflected in about:config and vice versa.
Comment 14 Peter Weilbacher 2004-11-26 17:49:11 PST
Comment on attachment 163247 [details] [diff] [review]
UI prefs for mousewheel.horizscroll.* prefs

Actually, this is probably better reviewed by the XPFE owners, although bryner
seems to be the expert on mousewheel scrolling...
Comment 15 Hiro 2004-11-29 23:30:03 PST
*** Bug 272095 has been marked as a duplicate of this bug. ***
Comment 16 Ian Neal 2004-12-05 09:45:28 PST
I think the change to help needs some work - it is just tagged on at the end
rather than being incorporated into the existing text. For example:

The line "The Mouse Wheel preferences panel allows you to control how the mouse
wheel on your mouse (in between your mouse buttons) is used in Mozilla:"
probably needs to make reference to the fact the user's mouse might have
multiple wheels or one that the direction can be adjusted. I only have a
standard wheel mouse so I'm not sure if there is a standard place for these
extra features to be on an advanced wheel mouse - if there is one, maybe that
needs to be mentioned as it is for the standard wheel mouse.

Perhaps - "The Mouse Wheel preferences panel allows you to control how the
vertical mouse wheel (in between your mouse buttons) and the horizontal mouse
wheel (<location of wheel> - if you have one) on your mouse are used in Mozilla:"
Comment 17 Peter Weilbacher 2004-12-05 16:45:46 PST
Well, I thought that this would be explained somewhere in the mouse driver or
even OS help. But you are right, at least partly. And if I ever get review
comments for my patch I will certainly take your comments into account before it
gets checked in.
Comment 18 jag (Peter Annema) 2004-12-09 16:22:31 PST
Comment on attachment 163247 [details] [diff] [review]
UI prefs for mousewheel.horizscroll.* prefs

>Index: xpfe/components/prefwindow/resources/locale/en-US/pref-mousewheel.dtd
>===================================================================

> <!ENTITY scrollPgUpPgDn.label         "Scroll a page up or a page down">
> <!ENTITY scrollPgUpPgDn.accesskey     "p">
>+<!ENTITY scrollPgLtPgRt.label         "Scroll a page left or a page right">
>+<!ENTITY scrollPgLtPgRt.accesskey     "p">

Double definition of "p" as an accesskey.


>Index: extensions/help/resources/locale/en-US/cs_nav_prefs_advanced.xhtml
>===================================================================
>     <p><strong>Note</strong>: Each modifier key can be assigned to a different
>       function.</p>
>   </li>
>+  <li>For each key the upper box titled "Vertical scrolling" allows you to
>+    assign a function to the normal operation of the wheel. If your mouse
>+    allows you to switch the wheel into horizontal mode or has two wheels
>+    you can use the lower box titled "Horizontal scrolling" to make similar
>+    adjustments as for the vertical mode.</li>

</li> should be on its own line as per the previous entry.

Other than that it looks good to me (though I haven't closely examinated your
copy&paste skills).

Go ahead and discuss better wording for the help file.
Comment 19 neil@parkwaycc.co.uk 2004-12-09 16:39:26 PST
Comment on attachment 163247 [details] [diff] [review]
UI prefs for mousewheel.horizscroll.* prefs

The horizontal radios will need completely separate accesskeys to the vertical
radios. They may currently only work on the last tab but that's a separate bug.
While you're there, make sure none of them (old or new) are 'h' because that's
reserved for help.

I noticed you reindented enableField, please don't include whitespace fixes on
otherwise unchanged code blocks.

You don't need ids on your new <vbox>es, please remove them.

Finally I don't think that the help is sufficiently helpful.
Comment 20 Peter Weilbacher 2004-12-09 18:24:32 PST
Great, thanks for the reviews! Those are all easily changed, although the
accesskeys still only work in the last tab (the one with shift), but from neil's
comment I understand that as a known problem.

The wording of the help text is much harder, before I post everything again as a
full patch, here is my suggestion:

   The Mouse Wheel preferences panel allows you to control how the mouse wheel
   on your mouse (in between your mouse buttons) is used in Mozilla.
   Modern mice may have two wheels or a button that can be used to switch the
   scroll direction of the wheel. The behaviour for the vertical wheel function
   is set in the upper panel <strong>Vertical scrolling</strong> while the 
   horizontal mode is controlled by the lower panel <strong>Horizontal
   scrolling</strong>.

1st big item:
   [... in the small items add "characters" in brackets after lines 
        and left/right after up/down ...]
2nd big item:
   If your mouse does not have a mode for horizontal scrolling, any setting
   in the lower panel <strong>Horizontal scrolling</strong> will be ignored.

One could add another item about mice with back/forward buttons but I think that
goes to far here, and I don't have a mouse like that so I can only guess from
bug 64485 what should be happening.
Comment 21 Peter Weilbacher 2004-12-10 07:23:52 PST
Steven Hunter writes me:

> > 2nd big item:
> >    If your mouse does not have a mode for horizontal scrolling, any
> >    setting in the lower panel <strong>Horizontal scrolling</strong>
> >    will be ignored.
>
> Maybe I'm misunderstanding something here, but this statement doesn't
> jive with the intent of the "bug" in question.
>
> The point of the bug was to request that the Mouse Wheel pref panel list
> "Scroll the document horizontally" as a choice for the wheel action. Your
> comment seems to imply supporting mice with secondary wheels only for
> such scrolling.

I think you are right that I may have misunderstood the original intent of the
bug when I first found it. Since then I never read the old comments again. It's
a bit stupid because noone objected two months ago or at least when I added my
ideas and the first draft of my patch.
What's the best procedure now? I guess I need to open a new bug and attach the
new patch there... Objections?
Comment 22 jag (Peter Annema) 2004-12-10 14:40:02 PST
Yeah, that would probably be the best way to go. Wow, I completely missed the
original request, which I think would be really nice to have (having run into
this desire myself on many occassions).
Comment 23 Peter Weilbacher 2004-12-11 05:08:50 PST
OK, none of the other horizontal mouse wheel bugs really applied, so I created
bug 274179 and attached the patch there. Sorry again, I also change back this
bug's title, as the required patch obviously requires some backend changes in
addition to the UI.
Comment 24 Hiro 2005-01-17 23:57:18 PST
*** Bug 277567 has been marked as a duplicate of this bug. ***
Comment 25 Hiro 2005-01-17 23:58:12 PST
*** Bug 241824 has been marked as a duplicate of this bug. ***
Comment 26 Hiro 2005-01-27 05:04:08 PST
*** Bug 248251 has been marked as a duplicate of this bug. ***
Comment 27 Hiro 2005-01-27 05:07:57 PST
*** Bug 235310 has been marked as a duplicate of this bug. ***
Comment 28 Hiro 2005-01-27 05:11:06 PST
*** Bug 218646 has been marked as a duplicate of this bug. ***
Comment 29 Hiro 2005-01-27 05:17:47 PST
*** Bug 176278 has been marked as a duplicate of this bug. ***
Comment 30 Matthew Schultz 2005-02-21 08:58:33 PST
I don't know if this should be included in this enhancement or I should create a
new one but it would be nice for the people who don't have a horizontal
scrolling mouse to have horizontal scrolling capabilities with the mouse.  If
anyone has ever used Textpad, you might know what I'm talking about.  In this
program when a horizontal scrollbar exists, it is possible to press and hold the
control key and use the vertical scroll on the mouse to scroll left and right. 
So would it be possible to hold the ctrl key + up scroll to scroll left and ctrl
key + down to scroll right?  I could envision just including the same option
Scroll a page left or right under the vertical scrolling area as well.
Comment 31 Steven Hunter 2005-02-21 10:00:53 PST
(In reply to comment #30)

Uh, if you'll re-read the description, that's already the goal of this bug.
Comment 32 Matthew Schultz 2005-02-22 00:18:47 PST
I was just looking into the new options in the latest nightly build and the
newest options under mouse wheel.  I suppose left/right scrolling under vertical
scrolling will be a later patch?
Comment 33 Christian Persch (GNOME) (away; not receiving bug mail) 2005-06-01 10:56:18 PDT
Created attachment 185037 [details] [diff] [review]
backend-only patch

Let's proceed step-by-step. Here's a patch implementing the backend support for
scrolling the other direction with the mouse wheel, which I need for embedding
(Epiphany).
It adds wheel actions 4 and 5, which scroll by numlines resp. by pagesize in
the other direction (i.e. horizontal for wheel, vertical for horiz wheel).
Comment 34 Dave Townsend [:mossop] 2005-08-05 04:08:53 PDT
*** Bug 303537 has been marked as a duplicate of this bug. ***
Comment 35 Ben 2005-08-05 04:45:06 PDT
Supposedly my bug 303537 is a duplicate of this bug.

I fail to see why because :
(a) This appears to be a bug restricted to the Microsoft Windows platform
(b) The Macintosh version of Mozilla doesn't even have
"Preferences->Advanced->Mouse Wheel"

Comment 36 Jo Hermans 2005-08-05 05:01:38 PDT
(In reply to comment #35)
> (b) The Macintosh version of Mozilla doesn't even have
> "Preferences->Advanced->Mouse Wheel" 

I thought you were using Firefox ?

Comment 37 Ben 2005-08-05 05:43:06 PDT
Typo ... Mozilla Firefox 1.0.6 ...sorry about confusion caused.
Comment 38 Jo Hermans 2005-08-05 06:28:43 PDT
*** Bug 258190 has been marked as a duplicate of this bug. ***
Comment 39 Matthew Schultz 2005-08-05 11:33:57 PDT
In Seamonkey Alpha (1.8b4) or Mozilla 1.8b, I go to Advanced->Mousewheel, then I
select the control tab and under Horizontal Scrolling, I select Scroll a page
left or a page right and hit ok.  Then when I press and hold ctrl and mouse
wheel up or down, the page does not scroll left or right when a scrollbar is
present.  Is there something in about:config I could configure or is the
backend-only patch not implemented yet?
Comment 40 Daniel Höpfl 2005-08-25 05:33:02 PDT
Created attachment 193804 [details] [diff] [review]
Backend and all new Frontend

The backend only patch did not work flawlessly on the current nightly so I
patched by hand and added a frontend.

My first GUI idea was to use 2 neested tabboxes (H/V -> N/A/C/S) but this
looked quite odd. Now I'm using popups instead of radio buttons (2*5 buttons
just took up too much space). This gives you a quick overview without consuming
more space than available.

The "Use system default" has been moved into a seperate dialog ("Advanced...").


Things that are not in this patch (I need help here!):

- I would prefer to have "[ ] Use custom settings: ___ units." instead of "[x]
Use system default" since that's what you set up here. You *activate* your
custom settings you do not *deactivate* the system's settings. My problem is
that I do not want to make the entries in the users config invalid and I do not
know how to connect the checkbox to the negated setting. Do I have to set the
checkbox in JavaScript code here or is there an better way?

- There is no help for the advanced settings dialog. (Simply remove the "Help"
button?)

- I've never created a patch that contains a new file for mozilla. Was
appending a diff agains /dev/null the correct way? Means: does the attached
patch work for you?

- Was it correct to add the new file to xpfe/components/jar.mn and
embedding/config/xulprefs.mn? pref-mousewheel.xul was there so I think it's
right.

- I did not update the defaults for all mousewheel.* preferences. (I did not
find the right place to do so) It should set up the actions in a reasonable way
(less important) and set *all* settings in the advanced settings dialog to "Use
system defaults" (and "1 unit" as inactive custom value)
Comment 41 Daniel Höpfl 2005-09-05 07:04:32 PDT
Created attachment 194913 [details] [diff] [review]
Backend and all new Frontend (V2)

Changes to the attachement of comment #40:

- Now there is some help.

- Replaced "Do not use system defaults" by "Use custom settings"

- Fixed a Copy&Paste-error in the advanced dialog.
Comment 42 Peter Weilbacher 2005-09-06 01:59:50 PDT
Comment on attachment 194913 [details] [diff] [review]
Backend and all new Frontend (V2)

I tried the patch and noted several things:

- The new controls on the page do not fit the contents of the prefs panel
(clipped in width so that I don't see the arrows of the drop-downs, and I only
see the upper left corner of the Advanced button), even on my system and I know
that on other systems the panel appears even smaller

- The UI is confusing. Why do the options for horizontal scrolling appear in
the box for vertical scrolling as well (and vice versa)?

- What am I supposed to select if I want Ctrl-Scroll to give me horizontal
scrolling? Currently, I cannot get that to work.

I think a different approach is needed. If the user does not have a mouse with
horizontal wheel or an option to switch direction, then the lower half of each
panel is useless. Instead, Mozilla should be able to detect that (difficult to
do that cross-platform, and probably impossible on Linux), hide the lower part
and instead display a check box saying
    [_] Use this modifier to scroll horizontally
or something like that.
Comment 43 Daniel Höpfl 2005-09-06 10:20:33 PDT
> - The new controls on the page do not fit the contents of the prefs panel
> (clipped in width so that I don't see the arrows of the drop-downs, and I only
> see the upper left corner of the Advanced button), even on my system and I know
> that on other systems the panel appears even smaller

On my build (Mozilla Seamonkey, CVS, Linux) they fit in the dialog but perhaps
we could find a shorter text than the longest "Move back and forward in the
browsing history"?

"Navigate (through) browsing history"?

> - The UI is confusing. Why do the options for horizontal scrolling appear in
> the box for vertical scrolling as well (and vice versa)?

Isn't that what this bug is about: Setting up horizontal scrolling for vertical
mouse wheels?

> - What am I supposed to select if I want Ctrl-Scroll to give me horizontal
> scrolling? Currently, I cannot get that to work.

Under vertical scrolling, in the popup next to "Control:" select "Scroll the
document left or right"

Would "Vertical/Horizontal wheeling" be a better title?

> I think a different approach is needed. If the user does not have a mouse with
> horizontal wheel or an option to switch direction, then the lower half of each
> panel is useless. Instead, Mozilla should be able to detect that (difficult to

I agree that it would be great if we could hide the useless box. It would be
very hard to do it right, the wheel could dis-/appear during the runtime,
multiple mice on a computer, ...

> do that cross-platform, and probably impossible on Linux), hide the lower part
> and instead display a check box saying
>     [_] Use this modifier to scroll horizontally
> or something like that.

You would have to display 8 checkboxes in the dialog.

Two possible scenarios:

- These checkboxes has to be disabled if there is something selected that does
not "scroll" the document.

- The popup has to be disabled if the checkbox is selected. The checkbox next to
the associated horizontal scrolling popup is disabled too, to prevent "H -> V ->
H -> ..."

Instead of the checkboxes there could be a item in the popup: "Pose as
horizontal". This has the same loop-problem.

My suggestion has none of these problems. No dependencies between the settings,
just a straight forward: "I want my vertical mouse wheel with pressed control
key to scroll the document left or right."
Comment 44 Peter Weilbacher 2005-09-07 02:49:06 PDT
(In reply to comment #43)
> > - The UI is confusing. Why do the options for horizontal scrolling appear in
> > the box for vertical scrolling as well (and vice versa)?
> 
> Isn't that what this bug is about: Setting up horizontal scrolling for vertical
> mouse wheels?

I was wrong about what this bug wants before, but yes, I think that is its
purpose. That does not mean that the "Vertical scrolling" box is the most
obvious place to add this function, after all, users would look in this box for
changing the movement in the vertical direction.

> > - What am I supposed to select if I want Ctrl-Scroll to give me horizontal
> > scrolling? Currently, I cannot get that to work.
> 
> Under vertical scrolling, in the popup next to "Control:" select "Scroll the
> document left or right"

Ah, OK, that works now. (I was quite sure that I had selected that as well
yesterday, strange...)

> Would "Vertical/Horizontal wheeling" be a better title?

I think "wheeling" has a different meaning in English.

> > do that cross-platform, and probably impossible on Linux), hide the lower part
> > and instead display a check box saying
> >     [_] Use this modifier to scroll horizontally
> > or something like that.
> 
> You would have to display 8 checkboxes in the dialog.

No, just one on each of the current four tabs. Once it is selected the
horizontal box controls are deactivated and all horizscroll prefs are set so
that they get deactivated. I will try to take a look at this the next days and
if I have enough time come up with an alternative patch to demonstrate my idea.

CCing neil and jag, perhaps they have some ideas or opinions.
Comment 45 neil@parkwaycc.co.uk 2005-09-14 06:12:23 PDT
Three ideas, but I haven't thought them out thoroughly:
1. Move all the horizontal scroll/extra button prefs into an advanced dialog
2. Radio buttons to choose between vertical/horizontal prefs
   (keeping the current modifier layout, but with two extra radio buttons)
3. Make the tabs vertical/horizontal, and list the modifiers vertically,
   two lines per modifier (action dropdown and number of lines textbox).
Comment 46 Peter Weilbacher 2005-11-02 16:05:33 PST
(In reply to comment #44)
> I will try to take a look at this the next days and
> if I have enough time come up with an alternative patch to demonstrate my idea.

I'm sorry, I just didn't find the time to really look into this, but ...

(In reply to comment #45)
> 2. Radio buttons to choose between vertical/horizontal prefs
>    (keeping the current modifier layout, but with two extra radio buttons)

... this is the option I had in mind.

> 3. Make the tabs vertical/horizontal, and list the modifiers vertically,
>    two lines per modifier (action dropdown and number of lines textbox).

This also sounds interesting.
Comment 47 Matthew Schultz 2005-12-22 09:12:55 PST
Any chance this patch will be applied for Seamonkey 1.0 final?
Comment 48 Ian Neal 2005-12-22 10:30:14 PST
(In reply to comment #47)
> Any chance this patch will be applied for Seamonkey 1.0 final?
> 
Without a new, reviewed patch - very doubtful
Comment 49 Daniel Höpfl 2006-01-12 12:07:22 PST
I stole some time to have a look at this patch again:

(In reply to comment #44)

> No, just one on each of the current four tabs. Once it is selected the
> horizontal box controls are deactivated and all horizscroll prefs are
> set so that they get deactivated.

Did I get this wrong: You would disallow me to set up the horizontal wheel because I have set up the vertical wheel to horizontal scrolling? What about Shift-vertical: Horizontal, Shift-horizontal: History.
Comment 50 Peter Weilbacher 2006-01-12 13:20:24 PST
I am not in the position to disallow anything, I am not an official reviewer nor part of the council.
But in the context of this bug this suggestion doesn't make much sense. As far as I understand this bug is for people who only have one scrollwheel and still want to switch from vertical to horizontal movement.
Comment 51 Daniel Höpfl 2006-01-12 14:19:18 PST
Created attachment 208305 [details] [diff] [review]
Backend and all new Frontend (V3)

This is a (partially) the implementation of idea 3 from Comment #45.

I dont't like the idea to see the options for overriding the system setting four times in the dialog.

Normally I would expect that whoever wants to change the scrolling speed does want this in all application so she should change the system preferences instead. If you really want it for Mozilla only (e.g. to set "slow scrolling" to Shift-scroll) you still can do so in the advanced preferences.

Normally you do not need the settings so why confuse the user with it?

Personally I really like V2 of the patch. It's a simple interface that shows everything at once most people ever want to change.
Comment 52 Daniel Höpfl 2006-01-12 14:21:50 PST
(In reply to comment #50)
> I am not in the position to disallow anything, I am not an official reviewer
> nor part of the council.

Sorry, should have been:

You would disallow *the user* to set up the horizontal wheel
because *she* has set up the vertical wheel to horizontal scrolling?.
Comment 53 Peter Weilbacher 2006-01-14 13:39:09 PST
No, it's just very confusing. And users who really have a "horizontal" wheel probably very rarely get the idea to use it for vertical scrolling if there is a vertical wheel... (Are there devices where the only wheel is really oriented horizontally?)


Anyway, about your patch. Now that I see the option with drop-downs in action I think I like it. Some suggestions:

- Rename vertical and horizontal wheel. Perhaps use "mouse wheel" (or "first mouse wheel" but that is stupid for people with only one wheel) and "second mouse wheel", to be less confusing. You could explain in the help text that the  normal wheel is normally set for vertical scrolling the second one for horizontal scrolling.

- You have a lot of free space in that panel now which could be used better. Yes, you don't want to confuse the user with too many options but now you have everything there twice (almost doubling the codesize) while the checkbox with entry field would nicely fit behind the drop-downs. 

- You could even think about removing the two tabs and instead place the second mouse wheel below the first. I think the longest panel currently is "Navigator -> Tabbed Browsing" which you could compare to.

- One drawback of this combined approach is that you have to use "units" whick really says nothing. Before, you could differentiate between lines (for vertical movement) and characters (horizontal), even if it was not always exact. If you had the checkbox+entry field behind the drop-downs, you could control this word by some JS magic depending on the selection in the corresponding drop-down.

- In the advanced panel, the selection of custom units is always selectable, even when "Move through browsing history" is selected. This doesn't make any sense. (Again, if you would put those extra options into the main panel it would probably be easier to control the correlation between them.)
Comment 54 Brian Ryner (not reading) 2006-02-19 00:33:32 PST
I'm not going to realistically have time to deal with this bug.  -> nobody, and unsetting reviews... sorry.
Comment 55 Matthew Schultz 2006-02-19 22:58:35 PST
Geez, there is a possible working patch and all it needs is a review and no one has the time to review it?  I miss that feverish pace before Fireferret took over.
Comment 56 John Mellor (Jomel) 2006-05-26 08:39:20 PDT
FWIW Internet Explorer Beta 2 adds this, Alt+wheelscroll scrolls the page horizontally; though they say in the final version they'll change the Alt modifier to Ctrl+Shift so it doesn't activate the File menu.
Comment 57 Jason Quinn 2008-07-25 07:16:20 PDT
Just wanted to add that compiz uses alt- and ctrl- mouse wheel for dimming  windows and zooming the desktop, respectively; so this reinforces that shift-mouse wheel is the way to go. 
Comment 58 Matthew Schultz 2008-07-25 07:37:11 PDT
(In reply to comment #57)
> Just wanted to add that compiz uses alt- and ctrl- mouse wheel for dimming 
> windows and zooming the desktop, respectively; so this reinforces that
> shift-mouse wheel is the way to go. 
> 

This feature (if it ever gets implemented), is about a configurable that allows you to choose what the modifier key is.
Comment 59 Lukasz Stelmach 2009-01-21 03:49:35 PST
I think it is worth considering to add transversal actions for both vertical and horizontal wheel just like in GIMP. So you can make the horizontal wheel scroll vertically too.
Comment 60 thomas 2013-01-26 12:50:37 PST
What is the current state of this feature? I'm still desperately looking for the functionality of scrolling horizontally when holding a choosable modifier key and using the *vertical* (i.e. up/down) mouse wheel. 

I'm using Firefox 18.0.1/Linux/KDE4.9.5. Is there already some way to achieve this with this setup (possibly with some about:config magic)?
Comment 61 Lonnie Lee Best 2013-09-20 10:54:01 PDT
I too am desperately seeking this functionality:
http://bugs.launchpad.net/bugs/1228250

Chrome and Chromium have this feature, and I want it too, but I use Firefox loyally.
Comment 62 Anand 2013-12-14 09:22:55 PST
Hi! I'm also a Firefox loyalist and have been searching desperately for this functionality. I've seen all sorts of options that *sort of* indicate that it *might* be available but nothing works.

Some webpages I've viewed:
- https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling#Preferences_for_customizing_delta_values_and_default_action
- http://forums.mozillazine.org/viewtopic.php?f=23&t=2072387
- https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling
- http://forums.mozillazine.org/viewtopic.php?f=38&p=12546047

These pages are related to this feature request but none of them provide an actual solution.

User @Skewer's original comment near the top of this issue says:

> Note that the traditional defaults are:
> Mouse wheel: Scroll vertically
> Ctrl+wheel: Zoom
> Shift+wheel: Pan (scroll horizontally)

The shift+wheel action (Pan / scroll horizontally) is *exactly* what I'm looking for.

Please help!
Comment 63 Bogdan Maris, QA [:bogdan_maris] 2013-12-31 02:39:11 PST
*** Bug 953136 has been marked as a duplicate of this bug. ***
Comment 64 Jan Keromnes [:janx] 2014-01-09 05:33:11 PST
oops
Comment 65 Jan Keromnes [:janx] 2014-02-03 03:18:58 PST
Created attachment 8369358 [details] [diff] [review]
Horizontal Scrolling with Mouse wheel+ modifier key
Comment 66 Jan Keromnes [:janx] 2014-02-03 03:43:16 PST
Comment on attachment 8369358 [details] [diff] [review]
Horizontal Scrolling with Mouse wheel+ modifier key

Review of attachment 8369358 [details] [diff] [review]:
-----------------------------------------------------------------

Currently, mousewheel pref actions can be set to 0:do nothing, 1:normal scroll, 2:navigate history and 3:zoom.

This patch adds option 4 to mousewheel pref actions in order to swap X and Y scroll deltas.

Example: Change "mousewheel.with_shift.action" to 4 so that Shift+Scroll scrolls horizontally.

André, can you take a look please?
Comment 67 Jan Keromnes [:janx] 2014-02-03 05:47:19 PST
Comment on attachment 8369358 [details] [diff] [review]
Horizontal Scrolling with Mouse wheel+ modifier key

Review of attachment 8369358 [details] [diff] [review]:
-----------------------------------------------------------------

Currently, mousewheel pref actions can be set to 0:do nothing, 1:normal scroll, 2:navigate history and 3:zoom.

This patch adds option 4 to mousewheel pref actions in order to swap X and Y scroll deltas.

Example: Change "mousewheel.with_shift.action" to 4 so that Shift+Scroll scrolls horizontally.

André, can you take a look please?
Comment 68 Anand 2014-02-03 05:54:05 PST
@Jan Keromnes: Thank you very much for picking up this issue! It's a constant pain point for me!!! :o)
Comment 69 Jan Keromnes [:janx] 2014-02-03 05:57:48 PST
Comment on attachment 8369358 [details] [diff] [review]
Horizontal Scrolling with Mouse wheel+ modifier key

(sorry for double posting, no need for two reviews)
Comment 70 Jan Keromnes [:janx] 2014-02-03 06:39:29 PST
You're very welcome Anand :) I couldn't bear this anymore.
Comment 71 André Reinald 2014-02-03 07:06:19 PST
Comment on attachment 8369358 [details] [diff] [review]
Horizontal Scrolling with Mouse wheel+ modifier key

Review of attachment 8369358 [details] [diff] [review]:
-----------------------------------------------------------------

It looks good to me.
You may want to also ask Masayuki Nakano, he's got more experience than myself on those things.
Comment 72 Jan Keromnes [:janx] 2014-02-03 08:12:39 PST
Thanks André! I'll ask Masayuki to review as well.
Comment 73 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2014-02-03 17:53:20 PST
Comment on attachment 8369358 [details] [diff] [review]
Horizontal Scrolling with Mouse wheel+ modifier key

I believe that you want to swap the scroll direction completely. However, your patch just swap the scroll direction of default action of wheel event. E.g., scrollable element implemented with JS is scroll normally with this patch. You need to swap the delta values before handling all of them.

I.e., You need to swap them in PreHandleEvent() (after applying delta_multiplier prefs?). And also you need to swap lineOrPageDeltaX and lineOrPageDeltay at same time. Finally, you might need to swap overflowDeltaX and overflowDeltay at the end of PostHandleEvent().

Additionally, you have to test new behavior with automated tests:

* Add new function to test if deltaX/deltaY are swapped in DOM event level.
http://mxr.mozilla.org/mozilla-central/source/dom/events/test/test_dom_wheel_event.html?force=1

* doTestScroll() should be run again with swapped pref. And also you need to test overflowX/Y are swapped correctly.
http://mxr.mozilla.org/mozilla-central/source/dom/events/test/window_wheel_default_action.html?force=1

* Please test it with native scroll event (this is now only available on Windows)
http://mxr.mozilla.org/mozilla-central/source/widget/tests/window_mouse_scroll_win.html?force=1

However, I don't think that this is good patch because this may make the code difficult to maintain. Therefore, basically, I don't agree with adding this feature suggested by this bug. How many people still want this feature? In these days, most pointing devices support horizontal scroll with tilt wheel or swipe gesture. Why this isn't enabled in default settings? These fact means that this makes the code complicated only for a few users. I'm not sure if this is worthwhile to fix this bug. I want to suggest this bug marked as WONTFIX. Could you explain why do we need to fix this bug even with such cost and appending risk?
Comment 74 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2014-02-03 17:57:07 PST
And I'd like to know if other browsers have this feature?
Comment 75 nandhp 2014-02-03 21:41:54 PST
> How many people still want this feature? In these days, most pointing devices support horizontal scroll with tilt wheel or swipe gesture.

Well, since you asked, here's the history of my horizontal scrolling capability.

First, my desktop still has a 1-dimensional wheel. After all, mice aren't the kind of gadget that have compelling reasons for people to upgrade them every six months.

On the other hand, my laptop is my primary computer, and I've recently upgraded to one with two-finger scrolling (in 2D). In fact, I've even written a Firefox extension (Scrolling Gestures) to take advantage of the horizontal scrolling capability. As a result, I've been untrained from using shift+scrolling and this feature isn't as important to me as it was a year ago (when each of my computers had only 1D scrolling).

> scrollable element implemented with JS is scroll normally with this patch

Do you mean, it will appear to JavaScript like Shift+Up and down? Bear in mind that there are two separate events for capturing wheel events; one ignores the axis and the other does not. There is at least one webapp (pressdisplay.com) that requires shift+vertical scrolling because of this. Here's a JSfiddle that demonstrates this: http://jsfiddle.net/SXAUx/7/ . Also, for the axis-capable event, shift-scrolling in Chrome reports only horizontal wheel events (even for shift+horizontal).

> And I'd like to know if other browsers have this feature?

Chrome has this feature. It also works in some other software, at least on Linux, like Evince (the GNOME PDF viewer).

I still think this feature is useful, even if I don't need it myself. However, I don't maintain Mozilla's scrolling code, so (speaking only for myself) if it's really too problematic to implement, I'm willing to concede.
Comment 76 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2014-02-03 22:18:20 PST
(In reply to nandhp from comment #75)
> First, my desktop still has a 1-dimensional wheel. After all, mice aren't
> the kind of gadget that have compelling reasons for people to upgrade them
> every six months.

Well, but horizontal scroll is supported on Vista or later with native message. So, all major platforms now support it in native level. I.e., the problem occurs only on WinXP or with mice or touchpads which don't support horizontal scroll. On such environment, the users really want a way of horizontal scroll by their device's vertical scroll operation? I'm not sure the strong reason why we need to implement this.

Additionally, I think that most web developers don't design such pages which needs to be scrolled horizontally. Actually, I don't use horizontal scroll in most web pages...

> > scrollable element implemented with JS is scroll normally with this patch
> 
> Do you mean, it will appear to JavaScript like Shift+Up and down?

I meant that some web pages have their own scrollbar for sub frames which handle DOM wheel events. I believe that users want to scroll them horizontally with the new setting.

However, if it's enabled in default settings of Shift or something, web pages never handle raw deltaX/Y values with the modifier state. Of course, it's bad thing, though...

> Bear in
> mind that there are two separate events for capturing wheel events; one
> ignores the axis and the other does not. There is at least one webapp
> (pressdisplay.com) that requires shift+vertical scrolling because of this.
> Here's a JSfiddle that demonstrates this: http://jsfiddle.net/SXAUx/7/ .
> Also, for the axis-capable event, shift-scrolling in Chrome reports only
> horizontal wheel events (even for shift+horizontal).

On Mac, we support diagonal wheel event (i.e., both deltaX and deltaY may be not 0 of a wheel event). So, discarding native event's deltaY information does not make sense. So, just swapping deltaX and deltaY does make sense to me.

> > And I'd like to know if other browsers have this feature?
> 
> Chrome has this feature. It also works in some other software, at least on
> Linux, like Evince (the GNOME PDF viewer).
> 
> I still think this feature is useful, even if I don't need it myself.

If so, why don't you change the default settings? I don't think it isn't worthwhile to implement such complicated behavior only for hidden feature.

> However, I don't maintain Mozilla's scrolling code, so (speaking only for
> myself) if it's really too problematic to implement, I'm willing to concede.

I think that swapping delta values may be broken easy by any changes around wheel handling code in nsEventStateManager. If we take your patch, we have to have a lot of tests for preventing regression bugs in the future.
Comment 77 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2014-02-03 22:23:01 PST
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #76)
> (In reply to nandhp from comment #75)
> > I still think this feature is useful, even if I don't need it myself.
> 
> If so, why don't you change the default settings?

Oops, you're not janx. But I still wonder why we need to implement a complex feature which is not enabled in default settings.
Comment 78 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2014-02-03 22:53:39 PST
Sorting out my concern:

1. Many people still want this in these days?
2. If it's not enabled in default settings, how many people would use (realize) this feature?
3. If it doesn't swap DOM wheel event's delta values, users won't scroll custom scrollable elements implemented with JS horizontally.
4. If it's enabled in default settings, web applications NEVER receive raw delta values with Shift key or other modifier. It's very bad thing for web application developers. E.g., game developers.
5. Swapping delta value may be broken easy at maintaining nsEventStateManager. For preventing it, we need a lot of automated tests as far as possible.
Comment 79 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2014-02-04 01:20:10 PST
Oh, Shift + Wheel is now navigating history on non-Mac platforms...
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#604
Comment 80 Jan Keromnes [:janx] 2014-02-04 01:52:24 PST
> Additionally, I think that most web developers don't design such pages which needs to be scrolled
> horizontally. Actually, I don't use horizontal scroll in most web pages...

Actually if you like to split your screen and use your browser only on one half of it, you're going to realize that most web pages are too large and therefore broken.

> And I'd like to know if other browsers have this feature?

It's expected standard behaviour in software handling 2D surfaces (e.g. a web page). In my experience, Shift+Scroll scrolls horizontally in Chrome, Gimp, Evince, Photoshop, MSPaint. Some programs use other modifier keys to scroll horizontally, hence the idea to make it configurable in prefs.

> 1. Many people still want this in these days?

I would guess so. Many people still use 1D scrolling (either with mouse or basic touchpad) and Shift+Scroll is a good standard way to scroll horizontally, even better than tilt wheels or trackpads in my opinion because you get the speed and control of a scrollwheel/touchpad.

> 2. If it's not enabled in default settings, how many people would use (realize) this feature?

Giving frustrated users no option to enable this is bad. Currently, searching for how to enable this feature in firefox gives a lot of "not possible, use chrome", a few strange addons, and eventually this bug (or one of the 9 other duplicates).

> 3. If it doesn't swap DOM wheel event's delta values, users won't scroll custom scrollable elements
> implemented with JS horizontally.

That sounds like a minor problem that could be fixed in this bug or a follow-up.

> 4. If it's enabled in default settings, web applications NEVER receive raw delta values with Shift key
> or other modifier. It's very bad thing for web application developers. E.g., game developers.

I think you're wrong here, because web applications already do not receive raw delta values / modifier in case of Shift+Scroll: In default Firefox, they see the user back up in his history, and as nandhp said in default Chrome they see a horizontal scroll event.

> 5. Swapping delta value may be broken easy at maintaining nsEventStateManager. For preventing it, we
> need a lot of automated tests as far as possible.

I'm willing to address your nits to my patch and add reasonable test coverage for it.

> Oops, you're not janx. But I still wonder why we need to implement a complex feature which is not
> enabled in default settings.

It doesn't look that complex. Changing the default behavior would probably surprise users who are used to navigating their history with Shift+Scroll. But hscroll is a feature that makes sense and needs to be configurable in firefox.

> Oh, Shift + Wheel is now navigating history on non-Mac platforms...

I find this default behaviour extremely annoying, because coming from Chrome I have the Shift+Scroll reflex, and every time I want to hscroll I find myself back on my homepage!
Comment 81 Jan Keromnes [:janx] 2014-02-04 02:11:18 PST
I forgot to say thank you for the very helpful and detailed review, Masayuki. I'll follow your suggestions, add tests, and ask for another review when I'm done.
Comment 82 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2014-02-04 02:31:52 PST
(In reply to Jan Keromnes [:janx] from comment #80)
> > 2. If it's not enabled in default settings, how many people would use (realize) this feature?
> 
> Giving frustrated users no option to enable this is bad. Currently,
> searching for how to enable this feature in firefox gives a lot of "not
> possible, use chrome", a few strange addons, and eventually this bug (or one
> of the 9 other duplicates).

Hmm, even if so, I still think that the new feature should be enabled in default settings (Alt + Wheel?).

> > 3. If it doesn't swap DOM wheel event's delta values, users won't scroll custom scrollable elements
> > implemented with JS horizontally.
> 
> That sounds like a minor problem that could be fixed in this bug or a
> follow-up.

I think that we should decide it in this bug. Smaug, how do you think? I believe that if we'd swap deltaX/deltaY for default action, DOM wheel event and legacy mouse scroll events should represent it. However, if we do so in default settings, there is an issue mentioned in #4 (below).

> > 4. If it's enabled in default settings, web applications NEVER receive raw delta values with Shift key
> > or other modifier. It's very bad thing for web application developers. E.g., game developers.
> 
> I think you're wrong here, because web applications already do not receive
> raw delta values / modifier in case of Shift+Scroll: In default Firefox,
> they see the user back up in his history,

No, web pages/applications can cancel it with a call of preventDefault().

> and as nandhp said in default
> Chrome they see a horizontal scroll event.

I feel it's bad behavior...

> > Oops, you're not janx. But I still wonder why we need to implement a complex feature which is not
> > enabled in default settings.
> 
> It doesn't look that complex. Changing the default behavior would probably
> surprise users who are used to navigating their history with Shift+Scroll.

Indeed. It depends on that we should give priority to compatibility with Chrome or our traditional behavior.

We should ask somebody who works on UX of Firefox for default setting change. I don't know who is good person for it, though.
Comment 83 Anand 2014-02-04 08:12:59 PST
(In reply to Jan Keromnes [:janx] from comment #80)
> > Additionally, I think that most web developers don't design such pages which needs to be scrolled
> > horizontally. Actually, I don't use horizontal scroll in most web pages...
> 
> Actually if you like to split your screen and use your browser only on one
> half of it, you're going to realize that most web pages are too large and
> therefore broken.
> 
> > And I'd like to know if other browsers have this feature?
> 
> It's expected standard behaviour in software handling 2D surfaces (e.g. a
> web page). In my experience, Shift+Scroll scrolls horizontally in Chrome,
> Gimp, Evince, Photoshop, MSPaint. Some programs use other modifier keys to
> scroll horizontally, hence the idea to make it configurable in prefs.
> 
> > 1. Many people still want this in these days?
> 
> I would guess so. Many people still use 1D scrolling (either with mouse or
> basic touchpad) and Shift+Scroll is a good standard way to scroll
> horizontally, even better than tilt wheels or trackpads in my opinion
> because you get the speed and control of a scrollwheel/touchpad.
> 
> > 2. If it's not enabled in default settings, how many people would use (realize) this feature?
> 
> Giving frustrated users no option to enable this is bad. Currently,
> searching for how to enable this feature in firefox gives a lot of "not
> possible, use chrome", a few strange addons, and eventually this bug (or one
> of the 9 other duplicates).
> 
> > 3. If it doesn't swap DOM wheel event's delta values, users won't scroll custom scrollable elements
> > implemented with JS horizontally.
> 
> That sounds like a minor problem that could be fixed in this bug or a
> follow-up.
> 
> > 4. If it's enabled in default settings, web applications NEVER receive raw delta values with Shift key
> > or other modifier. It's very bad thing for web application developers. E.g., game developers.
> 
> I think you're wrong here, because web applications already do not receive
> raw delta values / modifier in case of Shift+Scroll: In default Firefox,
> they see the user back up in his history, and as nandhp said in default
> Chrome they see a horizontal scroll event.
> 
> > 5. Swapping delta value may be broken easy at maintaining nsEventStateManager. For preventing it, we
> > need a lot of automated tests as far as possible.
> 
> I'm willing to address your nits to my patch and add reasonable test
> coverage for it.
> 
> > Oops, you're not janx. But I still wonder why we need to implement a complex feature which is not
> > enabled in default settings.
> 
> It doesn't look that complex. Changing the default behavior would probably
> surprise users who are used to navigating their history with Shift+Scroll.
> But hscroll is a feature that makes sense and needs to be configurable in
> firefox.
> 
> > Oh, Shift + Wheel is now navigating history on non-Mac platforms...
> 
> I find this default behaviour extremely annoying, because coming from Chrome
> I have the Shift+Scroll reflex, and every time I want to hscroll I find
> myself back on my homepage!

Just wanna say that EVERYTHING @Jan Keromnes has answered is EXACTLY what I'm feeling. I've been a loyal Firefox user since around 2001. I live the net through it. In the very least, being able to *enable* this behaviour - if only through "about:config" - is very, very important to power users.

PS: It's not a good idea to assume that users will have mice with horizontal scroll, nor is it guaranteed that if they have horz-scroll on the mouse, that they'll actually use it that way. I have a Logitech G700 and I've mapped copy/paste to my left/right horz-scroll cause that's what I use practically once every two minutes while working.

Thanks for your efforts @everyone!
Comment 84 thomas 2014-02-04 11:54:02 PST
I have never owned a mouse with a horizontal scroll wheel, only ones with a tiltable a scroll wheel. It's horrible having to use those for scrolling horizontally as you have to press them several times rather than rotate a wheel. It feels much more natural to use the up/down wheel with a modifier key pressed.

Furthermore, this is standard behavior in quite a number of applications; to the ones already mentioned (Chrome, gimp, evince) I'd like to add Inkscape, Scribus, LibreOffice. For other applications like konqueror, okular, gwenview, qtcreator it's Alt+Scroll Wheel, but still it's possible.

I frequently find myself longing for that feature because I (have to) use large zoom levels and having to grab the scroll bar or scroll with Left/Right keys is much less comfortable. So I would be really happy if someone could provide a simple working solution! (o:
Comment 85 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2014-07-02 15:57:45 PDT
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #82) 
> > That sounds like a minor problem that could be fixed in this bug or a
> > follow-up.
> 
> I think that we should decide it in this bug. Smaug, how do you think? I
> believe that if we'd swap deltaX/deltaY for default action, DOM wheel event
> and legacy mouse scroll events should represent it. However, if we do so in
> default settings, there is an issue mentioned in #4 (below).

Doesn't sound like a minor problem.
Since widgets on web pages tend to emulate native scrollable areas, they should get events similar to
native viewport or other scrollable areas.

#4 is tricky, but I think we should favor the more common case, so swap. 
How does IE handle this? What does Chrome actually report in delta values?
Comment 86 Jan Keromnes [:janx] 2014-08-27 03:18:01 PDT
Thanks a lot for the encouragements! (especially Anand)

I'm very sorry to disappoint, but I don't have time to realistically fight this battle at the moment. If anyone feels like taking this bug, please do. You can even steal ownership of my patch and do comment 81.

Open needinfo for smaug's questions in comment 85.
Comment 87 Jens 2016-04-08 02:58:30 PDT
At least, there is an add-on that this now: https://addons.mozilla.org/en-US/firefox/addon/shift-scroll/ Works great for me!
Comment 88 xyzdragon 2016-04-22 02:49:45 PDT
14 years and such a basic feature still isn't working out-of-the box.
I don't even have words for this anymore.

Note You need to log in before you can comment on or make changes to this bug.