[Shift + Mouse-Scroll-Wheel] Does NOT Scroll Horizontally

Bug #1228250 reported by Lonnie Lee Best on 2013-09-20
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Wishlist
firefox (Ubuntu)
Undecided
Unassigned

Bug Description

In Chromium, I can scroll horizontally using my mouse-wheel by holding down the shift key while scrolling the mouse wheel.

Firefox is missing this very convenient page-navigation short-cut.

Use Case:

As my eyes age, I find myself always scaling up the web pages I read (by holding down crtl and scrolling my mouse wheel).

Doing this, often makes the page exceed the width of my monitor (hiding the right-side of the text I want to read) and produces a horizontal scroll bar at the bottom of the page.

At this point, since I've already used ctrl-scroll-mouse-wheel to magnify the page, it would be wonderful if I could use shift-scroll-mouse-wheel to horizontally-scroll the magnified page and therefore center the (previously cropped) text that I am wanting to read.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: firefox 24.0+build1-0ubuntu0.13.04.1
ProcVersionSignature: Ubuntu 3.8.0-30.44-generic 3.8.13.6
Uname: Linux 3.8.0-30-generic x86_64
NonfreeKernelModules: wl
AddonCompatCheckDisabled: False
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: lonnie 2161 F.... pulseaudio
 /dev/snd/pcmC0D0p: lonnie 2161 F...m pulseaudio
BrokenPermissions: sessionstore.bak (0o600, wrong owner)
BuildID: 20130911155223
Channel: Unavailable
Date: Fri Sep 20 11:02:07 2013
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2013-09-06 (14 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
IpRoute:
 default via 192.168.24.1 dev eth0 proto static
 192.168.24.0/24 dev eth0 proto kernel scope link src 192.168.24.198 metric 1
MarkForUpload: True
PrefSources:
 prefs.js
 [Profile]/extensions/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}/defaults/preferences/prefs-dwhelper.js
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=24.0/20130911155223 (In use)
RelatedPackageVersions:
 google-talkplugin 4.5.3.0-1
 icedtea-7-plugin 1.3.2-1ubuntu1.1
 totem-mozilla 3.6.3-0ubuntu6
 rhythmbox-mozilla 2.98-0ubuntu5
RunningIncompatibleAddons: False
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/14/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A09
dmi.board.name: 0P792H
dmi.board.vendor: Dell Inc.
dmi.board.version: A09
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A09
dmi.modalias: dmi:bvnDellInc.:bvrA09:bd04/14/2011:svnDellInc.:pnStudio1737:pvrA09:rvnDellInc.:rn0P792H:rvrA09:cvnDellInc.:ct8:cvrA09:
dmi.product.name: Studio 1737
dmi.product.version: A09
dmi.sys.vendor: Dell Inc.

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.

-> bryner

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.

*** Bug 171049 has been marked as a duplicate of this bug. ***

*** Bug 196516 has been marked as a duplicate of this bug. ***

I think that the OS should be All instead of just Windows 2000.

In , Vdvo (vdvo) wrote :

Indeed.

Created attachment 140146
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.

Great! Any chance for a binary patch for Win32? :)

Created attachment 140298
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.

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.

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.

Created attachment 163247
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 on attachment 163247
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...

*** Bug 272095 has been marked as a duplicate of this bug. ***

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:"

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 on attachment 163247
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 on attachment 163247
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.

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.

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?

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

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.

*** Bug 277567 has been marked as a duplicate of this bug. ***

*** Bug 241824 has been marked as a duplicate of this bug. ***

*** Bug 248251 has been marked as a duplicate of this bug. ***

*** Bug 235310 has been marked as a duplicate of this bug. ***

*** Bug 218646 has been marked as a duplicate of this bug. ***

*** Bug 176278 has been marked as a duplicate of this bug. ***

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.

(In reply to comment #30)

Uh, if you'll re-read the description, that's already the goal of this bug.

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?

In , Chpe (chpe) wrote :

Created attachment 185037
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).

*** Bug 303537 has been marked as a duplicate of this bug. ***

In , 935c (935c) wrote :

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"

(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 ?

In , 935c (935c) wrote :

Typo ... Mozilla Firefox 1.0.6 ...sorry about confusion caused.

*** Bug 258190 has been marked as a duplicate of this bug. ***

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?

Created attachment 193804
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)

Created attachment 194913
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 on attachment 194913
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.

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

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

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

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

Any chance this patch will be applied for Seamonkey 1.0 final?

(In reply to comment #47)
> Any chance this patch will be applied for Seamonkey 1.0 final?
>
Without a new, reviewed patch - very doubtful

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.

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.

Created attachment 208305
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.

(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?.

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

I'm not going to realistically have time to deal with this bug. -> nobody, and unsetting reviews... sorry.

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.

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.

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.

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

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.

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

Also, most mouse-scroll-wheels (these days) have the ability for you to click your mouse-wheel.

If you press down on your scroll wheel, while scrolling, this too should allow you to scroll horizontally in Firefox.

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.

If the grease-monkey firefox addon installed, I found this user-script as a work around:
http://userscripts.org/scripts/show/168193

Changed in firefox:
importance: Unknown → Wishlist
status: Unknown → Confirmed

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!

*** Bug 953136 has been marked as a duplicate of this bug. ***

oops

Created attachment 8369358
Horizontal Scrolling with Mouse wheel+ modifier key

Comment on attachment 8369358
Horizontal Scrolling with Mouse wheel+ modifier key

Review of attachment 8369358:
-----------------------------------------------------------------

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?

@Jan Keromnes: Thank you very much for picking up this issue! It's a constant pain point for me!!! :o)

Comment on attachment 8369358
Horizontal Scrolling with Mouse wheel+ modifier key

(sorry for double posting, no need for two reviews)

You're very welcome Anand :) I couldn't bear this anymore.

Comment on attachment 8369358
Horizontal Scrolling with Mouse wheel+ modifier key

Review of attachment 8369358:
-----------------------------------------------------------------

It looks good to me.
You may want to also ask Masayuki Nakano, he's got more experience than myself on those things.

Thanks André! I'll ask Masayuki to review as well.

Changed in firefox:
status: Confirmed → In Progress

Comment on attachment 8369358
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?

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

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

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

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

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.

Oh, Shift + Wheel is now navigating history on non-Mac platforms...
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#604

> 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!

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.

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

Download full text (3.7 KiB)

(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 Firefo...

Read more...

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:

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed

(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?

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.

Changed in firefox:
status: In Progress → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.