Closed Bug 143038 Opened 22 years ago Closed 7 years ago

Horizontal Scrolling with Mouse wheel+ modifier key

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement, P2)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla58
Tracking Flags:
Tracking Status
firefox58 --- fixed

People

(Reporter: hunters, Assigned: masayuki)

References

(Regressed 1 open bug)

Details

Attachments

(1 file, 8 obsolete files)

Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier
59 bytes, text/x-review-board-request
smaug
: review+
Details 
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.
see also bug 58589
Assignee: Matti → jaggernaut
Component: Browser-General → XP Toolkit/Widgets
QA Contact: imajes-qa → jrgm
-> bryner
Assignee: jaggernaut → bryner
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.

Indeed.
OS: Windows 2000 → All
Attached patch patch (only tested with gtk) (obsolete) — — Splinter Review 
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? :)
Attached file XUL (workaround) (obsolete) — 
(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.
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.
Attachment #163247 - Flags: review?(bryner)
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...
Attachment #163247 - Flags: superreview?(jag)
Attachment #163247 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #163247 - Flags: review?(bryner)
*** 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.
Summary: Horizontal Scrolling with Mouse wheel+ modifier key → Horizontal Scrolling with Mouse wheel+ modifier key (UI prefs panel)
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 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.
Attachment #163247 - Flags: review?(neil.parkwaycc.co.uk) → review-
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.
Attachment #163247 - Flags: superreview?(jag)
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.
Summary: Horizontal Scrolling with Mouse wheel+ modifier key (UI prefs panel) → Horizontal Scrolling with Mouse wheel+ modifier key
Attachment #163247 - Attachment is obsolete: true
*** 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?
Attached patch backend-only patch (obsolete) — — Splinter Review 
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).
Attachment #140146 - Attachment is obsolete: true
Attachment #185037 - Flags: review?(bryner)
*** Bug 303537 has been marked as a duplicate of this bug. ***
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 ?


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?
Attached patch Backend and all new Frontend (obsolete) — — Splinter Review 
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)
Attachment #193804 - Flags: review?(bryner)
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.
Attachment #193804 - Attachment is obsolete: true
Attachment #193804 - Flags: review?(bryner)
Attachment #194913 - Flags: review?(bryner)
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.
> - 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.
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.
Assignee: bryner → nobody
Attachment #185037 - Flags: review?(bryner)
Attachment #194913 - Flags: review?(bryner)
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.
QA Contact: jrgmorrison → xptoolkit.widgets
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)?
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.
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!
Flags: needinfo?
Flags: needinfo?
oops
Flags: needinfo?

        Attachment #185037 -
        Attachment is obsolete: true

        Attachment #194913 -
        Attachment is obsolete: true

        Attachment #208305 -
        Attachment is obsolete: true

    
    

    
  
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?

        Attachment #8369358 -
        Flags: review?(areinald)

    
    

    
  
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?

        Attachment #8369358 -
        Flags: review?(areinald)

    
    

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

    
    

    
  
Comment on attachment 8369358 [details] [diff] [review]
Horizontal Scrolling with Mouse wheel+ modifier key

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

        Attachment #8369358 -
        Flags: review?(areinald)
Flags: needinfo?

    
    

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

    
  
Assignee: nobody → janx
Status: NEW → ASSIGNED

    
    

    
  
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.

        Attachment #8369358 -
        Flags: review?(areinald) → review+

    
    

    
  
Thanks André! I'll ask Masayuki to review as well.
URL: http://www.foo.com/
Component: XUL → Document Navigation

    
  

        Attachment #8369358 -
        Flags: review?(masayuki)

    
    

    
  
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?

        Attachment #8369358 -
        Flags: review?(masayuki)

    
    

    
  
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.
Flags: needinfo?(bugs)

    
    

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

    
    

    
  
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:

    
    

    
  
(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?
Flags: needinfo?(bugs)

    
    

    
  
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.
Assignee: janx → nobody
Status: ASSIGNED → NEW

    
  
Priority: -- → P2
Hardware: x86 → All

    
    

    
  
At least, there is an add-on that this now: https://addons.mozilla.org/en-US/firefox/addon/shift-scroll/ Works great for me!

    
    

    
  
14 years and such a basic feature still isn't working out-of-the box.
I don't even have words for this anymore.

    
    

    
  
Why not merge code from this add-on (https://addons.mozilla.org/en-US/firefox/addon/shift-scroll/) be merged into upstream Firefox?
Should be easy to fix such a long standing bug.

    
    

    
  
(In reply to xyzdragon from comment #88)
> 14 years and such a basic feature still isn't working out-of-the box.
> I don't even have words for this anymore.


Agree 110% !!!

Meanwhile they keep on releasing increasingly bug-ridden and bloated new releases.  The latest version of Firefox on Mac just has browser tabs that keep on crashing for no reason.

Good riddance Mozilla, I should have trashed it a long time ago.

    
    

    
  
Shift+Scroll to scroll horizontally is still missing. This might seem like a small feature to have, but it actually has profound impact.

First of all, I belive the majority of mice still only have a vertical scroll wheel. At our university, every mouse falls into that category.

However, the major problem is providing a consistent interaction with horizontally scrolling containers across platforms/browsers. If one has to rely on a vertical scroll wheel, the approach would be listening for the `wheel` event and use `event.deltaY` for setting `scrollLeft` when `event.shiftKey === true`. Now this won’t lead to pleasent results right away since these deltas yield vastly different values across devices/browsers. Is it a trackpad? Does it fire the event very often? Is the delta very big or very small? Is the inertial scrolling behavior? In short, re-implementing scrolling behavior is very hard.

Turning a scroll wheel once results in roughly the same scrolling distance when comparing Chrome and Firefox. However the events’ delta values are different.

What does this have to do with this issue? Since there is no Shift+Scroll for horizontal scrolling, providing users with a way to do so also requires to re-implemented scrolling.

Users need a way of interacting with horizontally overflowing elements by scrolling natively.

    
    

    
  
I know it's not qt, but qt has this notion of QWheelEvent::DefaultDeltasPerStep – maybe gtk has that too?

Anyway, I recently implemented a fix for a problem in the linux KDE application gwenview, where, when you used CTRL+Touchpad_scroll to zoom in/out, it was horribly sensitive (see here for bug/patch https://bugs.kde.org/show_bug.cgi?id=378584#c7). For the fix we would always accumulate deltas upon triggered events and only perform the action once the accumulated delta is greater than or equal to QWheelEvent::DefaultDeltasPerStep (at the same time resetting the accumulated delta to 0).

Using the scroll wheel, the emitted delta is exactly QWheelEvent::DefaultDeltasPerStep, such that the action is performed at each turn of the wheel.

    
    

    
  
(In reply to Olli Pettay [:smaug] from comment #85)
> (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?

Looks like that IE/Edge doesn't have this feature since Shift+wheel causes navigating history like us. Chrome just swaps default action (i.e., not touching DOM event values).

I wonder, wheel related events are cancelable, that means that it does NOT represent default action's behavior. So, perhaps, we can just take the Chrome's behavior? (Even if web apps check their implementation only with Chrome, it won't cause any problem only on Firefox.) That's not ideal behavior from a point of view of DOM events, but low risk approach in the real world.

FYI: At bug 1358017 Comment 2, similar issue on vertical writing web pages, dbaron thinks that only changing default action is reasonable.

How about you?
Flags: needinfo?(bugs)

    
    

    
  
Ok, if some other browser (happens to be Chrome) doesn't change the delta values, we shouldn't either.
Flags: needinfo?(bugs)
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Component: Document Navigation → Event Handling

        Attachment #8369358 -
        Attachment is obsolete: true

        Attachment #140298 -
        Attachment is obsolete: true

    
    

    
      
  


  

    
    

    
  
I realized that due to e10s mochitests disabled, we won't test the default actions of wheel events without APZ. I manually ran the test without non-e10s mochitests.  Then, I confirmed that it's all green.

On the other hand, there is a known bug in the patch. The multiplier pref for X axis is applied to deltaY if the wheel event should be treated as horizontal scroll.  So, WheelEvent.deltaY may see odd delta value with it especially when the multiplier X is negative (meaning scroll direction is reversed) but multiplier Y is positive. With more complicated code, I can fix it, but I don't know if it's enough worthwhile...

    
    

    
  
hmm, yeah, perhaps that isn't even a bug but a feature.

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review192674

This is complicated enough, that I think I should re-read this after those small nits are fixed.

::: commit-message-19b32:26
(Diff revision 1)
> +restoring.
> +
> +So, this patch does NOT change any wheel event information on web apps.  Only
> +changes its default action.  This is same behavior as Chromium.
> +
> +Note that with this patch, users cannot navigate the tab's history with

Could you explain this. Currently shift+vertical wheel is back-forward. Does this new behavior override that feature always or only when it is enabled explicitly?

How is shift+horizontal supposed to work for back-forward if shift+vertical is for scrolling? One often gets both horizontal and vertical scrolling when using touchpad.

::: dom/events/EventStateManager.h:652
(Diff revision 1)
>       * If an .override_x value is -1, same as the
>       * corresponding mActions value.
>       */
>      Action mOverriddenActionsX[COUNT_OF_MULTIPLIERS];
>  
> +    // XXX Modifier is better than Modifiers.  However, it's defined in

That seems like a silly reason to not use Modifier.
If you're really worried about the build time change, why not just move Modifier to its own header?

::: dom/events/EventStateManager.cpp:5691
(Diff revision 1)
> +  }
> +
> +  Index index = GetIndexFor(aEvent->mModifiers &
> +                              ~mModifierToTreatVertialWheelAsHorizontalScroll);
> +  Init(index);
> +  // We need to cache this result in the widget.  Some methods of this class

Cache the result in the widget? I don't see anything stored in the widget.

::: dom/events/EventStateManager.cpp:5710
(Diff revision 1)
>      return INDEX_DEFAULT;
>    }
> +  if (!NeedToTreatAsHorizontalScroll(aEvent)) {
> +    return GetIndexFor(aEvent->mModifiers);
> +  }
> +#if 0

No ifdef 0 code, please

::: dom/events/EventStateManager.cpp:5837
(Diff revision 1)
>    Index index = GetIndexFor(aEvent);
>    Init(index);
>  
> +  // If the event should be treated as horizontal wheel operation, deltaY
> +  // should be applied mMultiplierX.  Note that deltaX and deltaZ are always
> +  // 0 in such case.  Therefore, we only need to use temporary variable only

Why they are 0?

::: dom/events/EventStateManager.cpp:5842
(Diff revision 1)
> +  // 0 in such case.  Therefore, we only need to use temporary variable only
> +  // for deltaY.  Additionally, if the event is being handled by default
> +  // handler, the deltaX and deltaY may be swapped.  Therefore, we need to
> +  // use mMultiplierX for deltaY only when the event should be treated as
> +  // horizontal scroll and mDeltaY isn't 0.
> +  auto multiplierForDeltaY = mMultiplierY[index];

Could you not use auto here. With auto I need to go to the mMultiplierY definition to see what the type of multiplierForDeltaY is.

::: dom/events/EventStateManager.cpp:5886
(Diff revision 1)
>      aEvent->mOverflowDeltaX /= mMultiplierX[index];
>    }
> -  if (mMultiplierY[index]) {
> -    aEvent->mOverflowDeltaY /= mMultiplierY[index];
> +
> +  // If the event should be treated as horizontal wheel operation, deltaY
> +  // should be applied mMultiplierX.  Note that deltaX and deltaZ are always
> +  // 0 in such case.  Therefore, we only need to use temporary variable only

Again, why they are 0?

::: dom/events/EventStateManager.cpp:5891
(Diff revision 1)
> +  // 0 in such case.  Therefore, we only need to use temporary variable only
> +  // for deltaY.  Additionally, if the event is being handled by default
> +  // handler, the deltaX and deltaY may be swapped.  Therefore, we need to
> +  // use mMultiplierX for deltaY only when the event should be treated as
> +  // horizontal scroll and mDeltaY isn't 0.
> +  auto multiplierForDeltaY = mMultiplierY[index];

Don't use auto, pretty please.

::: dom/events/WheelHandlingHelper.h:217
(Diff revision 1)
> + */
> +class MOZ_STACK_CLASS AutoTemporarilyWheelDeltaSwapper final
> +{
> +public:
> +  /**
> +   * @param aWheelEvent     A wheel event.  Must not be nullptr.

If so, perhaps make the ctor take WidgetWheelEvent& and store using that type too. That self-documents that it must not ever-never be null

        Attachment #8915954 -
        Flags: review?(bugs) → review-

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review192730

::: commit-message-19b32:26
(Diff revision 1)
> +restoring.
> +
> +So, this patch does NOT change any wheel event information on web apps.  Only
> +changes its default action.  This is same behavior as Chromium.
> +
> +Note that with this patch, users cannot navigate the tab's history with

Yes, when the new pref is enabled, the modifier (default value is Shift on non-macOS platforms) with vertical wheel overrides the default action.

the modifier with horizontal wheel or diagonal wheel operation works exactly same as current build. See NeedToTreatAsHorizontalScroll() implementation for the detail.

::: dom/events/EventStateManager.h:652
(Diff revision 1)
>       * If an .override_x value is -1, same as the
>       * corresponding mActions value.
>       */
>      Action mOverriddenActionsX[COUNT_OF_MULTIPLIERS];
>  
> +    // XXX Modifier is better than Modifiers.  However, it's defined in

Sure. I'll move it to EventForwards.h.

::: dom/events/EventStateManager.cpp:5691
(Diff revision 1)
> +  }
> +
> +  Index index = GetIndexFor(aEvent->mModifiers &
> +                              ~mModifierToTreatVertialWheelAsHorizontalScroll);
> +  Init(index);
> +  // We need to cache this result in the widget.  Some methods of this class

Ah, I meant in WidgetWheelEvent.

::: dom/events/EventStateManager.cpp:5710
(Diff revision 1)
>      return INDEX_DEFAULT;
>    }
> +  if (!NeedToTreatAsHorizontalScroll(aEvent)) {
> +    return GetIndexFor(aEvent->mModifiers);
> +  }
> +#if 0

Oops, sorry and nice catch!

::: dom/events/EventStateManager.cpp:5837
(Diff revision 1)
>    Index index = GetIndexFor(aEvent);
>    Init(index);
>  
> +  // If the event should be treated as horizontal wheel operation, deltaY
> +  // should be applied mMultiplierX.  Note that deltaX and deltaZ are always
> +  // 0 in such case.  Therefore, we only need to use temporary variable only

Because NeedToTreatAsHorizontalScroll() checks |if (aEvent->mDeltaX || !aEvent->mDeltaY || aEvent-DeltaZ)| and return false if it's true.

    
    

    
  
Oops, I used wrong form to reply to the review comments :-(

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review192674

> Could you explain this. Currently shift+vertical wheel is back-forward. Does this new behavior override that feature always or only when it is enabled explicitly?
> 
> How is shift+horizontal supposed to work for back-forward if shift+vertical is for scrolling? One often gets both horizontal and vertical scrolling when using touchpad.

Yes, when the new pref is enabled, the modifier (default value is Shift on non-macOS platforms) with vertical wheel overrides the default action.

the modifier with horizontal wheel or diagonal wheel operation works exactly same as current build. See NeedToTreatAsHorizontalScroll() implementation for the detail.

> That seems like a silly reason to not use Modifier.
> If you're really worried about the build time change, why not just move Modifier to its own header?

Sure. I'll move it to EventForwards.h.

> Cache the result in the widget? I don't see anything stored in the widget.

Ah, I meant in WidgetWheelEvent.

> No ifdef 0 code, please

Oops, sorry and nice catch!

> Why they are 0?

Because NeedToTreatAsHorizontalScroll() checks |if (aEvent->mDeltaX || !aEvent->mDeltaY || aEvent-DeltaZ)| and return false if it's true.

    
    

    
      
  

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review193228

Still r-, because I was surprised to see
"expected: kScrollDown | kScrollLeft" in case there is both vertical and horizontal scrolling with modifier.
Please explain or fix.

::: dom/events/test/window_wheel_default_action.html:1830
(Diff revision 2)
> +
> +  const kTests = [
> +    // Without modifier key, the default's action should be used.
> +    // I.e., vertical scroll is expected normally.
> +    { defaultActions: {
> +        default: 1, with_shift: 2, with_control: 3

What these numbers are? 1, 2, 3? Please add some comment

::: dom/events/test/window_wheel_default_action.html:1853
(Diff revision 2)
> +               deltaX: 0, deltaY: -1.0,
> +               lineOrPageDeltaX: 0, lineOrPageDeltaY: -1,
> +               shiftKey: false, ctrlKey: false, altKey: false },
> +      expected: kScrollUp
> +    },
> +    // If only the modifier to treat vertical wheel as horizontal scroll,

I don't understand this sentence.

::: dom/events/test/window_wheel_default_action.html:1914
(Diff revision 2)
> +      deltaMultiplierX: 1.0,
> +      deltaMultiplierY: 1.0,
> +      event: { deltaMode: WheelEvent.DOM_DELTA_LINE,
> +               deltaX: 0, deltaY: 1.0,
> +               lineOrPageDeltaX: 0, lineOrPageDeltaY: 1,
> +               shiftKey: true, ctrlKey: true, altKey: false },

Oh, modifier in the JS object isn't about the event but about the pref. Could you document that somewhere

::: dom/events/test/window_wheel_default_action.html:1981
(Diff revision 2)
> +               deltaX: 0, deltaY: -1.0,
> +               lineOrPageDeltaX: 0, lineOrPageDeltaY: -1,
> +               shiftKey: true, ctrlKey: true, altKey: false },
> +      expected: kScrollUp
> +    },
> +    // If the wheel is operated diagonally, shouldn't treat the deltaY as

This sounds wrong. If the pref is set, and modifier is pressed, why should viewport scroll ever horizontally? I don't see such behavior in Chrome on Windows

::: dom/events/test/window_wheel_default_action.html:2184
(Diff revision 2)
>      ["mousewheel.default.action.override_x", -1],
>      ["mousewheel.with_shift.action", 2],   // history
>      ["mousewheel.with_shift.action.override_x", -1],
>      ["mousewheel.with_control.action", 3], // zoom
> -    ["mousewheel.with_control.action.override_x", -1]]},
> +    ["mousewheel.with_control.action.override_x", -1],
> +    ["mousewheel.modifier_to_treat_vertical_wheel_as_horizontal_scroll", 0]]},

I don't understand this. Why 0? Doesn't that disable the feature.

::: modules/libpref/init/all.js:2759
(Diff revision 2)
> +// to one of 16 (Shift), 17 (Ctrl), 18 (Alt/Option) and 224 (Command), the
> +// corresponding modifier key with vertical scroll is treated as horizontal
> +// scroll.  Note that this setting may override the action set by
> +// "mousewheel.with_*.action" and mousewheel.with_*.action.override_x.  E.g.,
> +// when this is set to 16 (Shift) and "mousewheel.with_shift.action" is set to
> +// 2 (History Navigation), try to scrolling vertically with Shift key causes

s/try to//

::: widget/MouseEvents.h:597
(Diff revision 2)
>               mLineOrPageDeltaX : mLineOrPageDeltaY;
>    }
>  
> +  void SwapDeltaXAndDeltaY()
> +  {
> +    auto tmpDelta = mDeltaX;

I guess you could use std::swap here

        Attachment #8915954 -
        Flags: review?(bugs) → review-

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review193228

Because the tests set default action of both without any modifier and with shift to "scroll":
> default: 1, with_shift: 1, with_control: 3
Therefore, even if the new pref overrides "default"'s default action, it should be ignored (i.e., default action of with_shift should be executed) since the wheel operation is not only for vertical-wheel.

In other words, if with_shift is 2 as the default settings of non-macOS platforms, the diagonal wheel operation with Shift should cause navigating history. However, it's impossible to test it with this automated test.

> What these numbers are? 1, 2, 3? Please add some comment

Okay, I'll replace them with constants.

> I don't understand this sentence.

I meant "If only the modifier to trreat vertical wheel as horizontal scroll is active,"

> This sounds wrong. If the pref is set, and modifier is pressed, why should viewport scroll ever horizontally? I don't see such behavior in Chrome on Windows

On macOS, we may receive diagonal wheel operation events. In such case, we should not respect the new pref because the new pref is for legacy mouse device which only supports vertical wheel operation but the user's device is obviously supports horizontal wheel operation in this case. Do you think that we should enable this hack even in this case?

> I don't understand this. Why 0? Doesn't that disable the feature.

Yes. Because if we set a modifier key code here, I need to rewrite existing tests. And that needs special handling with this pref. I.e., that causes making the existing tests really complicated. Therefore, I think that we should keep running existing tests with disabling the new pref.  But the new feature should be tested by the new tests.

    
    

    
  
Requesting ni? for the above reply from MozReview.
Flags: needinfo?(bugs)

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review193228

> Oh, modifier in the JS object isn't about the event but about the pref. Could you document that somewhere

I'll rename it instead of documenting it.

    
    

    
  
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #108)

> On macOS, we may receive diagonal wheel operation events. In such case, we
> should not respect the new pref because the new pref is for legacy mouse
> device
How so? Isn't it for touchpads too.

> which only supports vertical wheel operation but the user's device is
> obviously supports horizontal wheel operation in this case. Do you think
> that we should enable this hack even in this case?
I don't know what hack.

How is this supposed to work on Windows + touchpad? On Chrome if shift is pressed, only
horizontal scrolling will happen.
Flags: needinfo?(bugs)

    
    

    
  
(In reply to Olli Pettay [:smaug] from comment #111)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #108)
> 
> > On macOS, we may receive diagonal wheel operation events. In such case, we
> > should not respect the new pref because the new pref is for legacy mouse
> > device
> How so? Isn't it for touchpads too.

Oh, really? I remembered as so. Just my memory is wrong or macOS's behavior has been changed (IIRC, starting Sierra, mouse scroll event behavior has been changed, it might be changed at this time).

> > which only supports vertical wheel operation but the user's device is
> > obviously supports horizontal wheel operation in this case. Do you think
> > that we should enable this hack even in this case?
> I don't know what hack.

I think the new feature is hack for the legacy mice.

> How is this supposed to work on Windows + touchpad? On Chrome if shift is
> pressed, only
> horizontal scrolling will happen.

On Windows, native event doesn't support diagonal scroll with an event. So, this case never occurs on Windows actually. (If user tries to scroll content diagonally, both vertical wheel event and horizontal wheel event are fired separately.) Although, it could occur with some touchscreen. However, I don't see wheel events when I scroll content in Gecko with my notebook's touchscreen.　(Pan gesture could fire wheel events, but I'm not familiar with this path: https://searchfox.org/mozilla-central/rev/1a4a26905f923458679a59a4be1e455ebc53c333/widget/windows/nsWinGesture.cpp#393,409-410,412-413 )

I'm not sure about GTK. GTK3's event has both delta values in an event. So, it could support diagonal scroll, but I don't have environment that Linux is installed on real machine (not virtual machine).

Anyway, I don't think that we should use this feature when the user's device is obviously non-legacy pointing device, i.e., it supports diagonal scroll. What do you think?
Flags: needinfo?(bugs)

    
    

    
  
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #112)
> (In reply to Olli Pettay [:smaug] from comment #111)
> > (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #108)
> > 
> > > On macOS, we may receive diagonal wheel operation events. In such case, we
> > > should not respect the new pref because the new pref is for legacy mouse
> > > device
> > How so? Isn't it for touchpads too.
> 
> Oh, really? I remembered as so. Just my memory is wrong or macOS's behavior
> has been changed (IIRC, starting Sierra, mouse scroll event behavior has
> been changed, it might be changed at this time).
Sorry, I was unclear. I was talking about touchpads on Windows. 
I have no idea about MacOS




> I'm not sure about GTK. GTK3's event has both delta values in an event. So,
> it could support diagonal scroll, but I don't have environment that Linux is
> installed on real machine (not virtual machine).
I see, on linux Chrome has odd behavior where it seems to allow vertical scrolling when diagonal scrolling is done. That behavior is really weird when one uses it. Makes scrolling feel like all broken since viewport is scrolled somewhat randomly. It is hard to control whether to do only up-down or left-right scrolling on a touchpad or a bit both.


> Anyway, I don't think that we should use this feature when the user's device
> is obviously non-legacy pointing device, i.e., it supports diagonal scroll.
> What do you think?
But this is enabled on touchpads too, if the pref is set. Could we somehow enable it on mouse input only, and not touchpad?
Flags: needinfo?(bugs)

    
    

    
  
(In reply to Olli Pettay [:smaug] from comment #113)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #112)
> > Anyway, I don't think that we should use this feature when the user's device
> > is obviously non-legacy pointing device, i.e., it supports diagonal scroll.
> > What do you think?
> But this is enabled on touchpads too, if the pref is set. Could we somehow
> enable it on mouse input only, and not touchpad?

Unfortunately, on any platforms, we cannot check if mouse scroll event came from what kind of device.

There are some options:

1. Take current approach -- treat "pure" vertical wheel operation as horizontal scroll and
  1-1. Handle deltaX as is (current approach).
  1-2. Handle deltaX as vertical scroll (I don't like this and incompatible with Chrome).
  1-3. Ignore deltaX, so, if only deltaX is non-zero, does nothing.
2. Treat any vertical wheel operation as horizontal scroll (even if it's diagonal operation) and/but
  2-1. Handle deltaX as vertical scroll (same as 1-2).
  2-2. Ignore deltaX (same as 1-3).

If user operates wheel diagonally but native events come separately, it might be the best to ignore deltaX. E.g., we can avoid performing 2 default actions (e.g., both horizontal scroll and navigating history), but this means that the default action will always be ignored if it matches with new pref's modifier.
Flags: needinfo?(bugs)

    
    

    
  
2-3. Handle deltaX as horizontal scroll too (but may cause too fast or slow scroll with diagonal wheel operation).

I like 1-1, 1-3 or 2-2.

    
    

    
  
1-3 or 2-2 sound reasonable to me.
Flags: needinfo?(bugs)

    
    

    
  
Okay, now, I think that 2-2 is the best here because:

1. if we ban diagonal wheel events with specific modifier key, horizontal scroll might be too slow if the device can cause diagonal scroll easily (even if user expects only vertical scroll).
2. if we also take deltaX as horizontal scroll, horizontal scroll might be too fast if user does diagonal scroll.

Then, we can treat the new action as simple default action. I'll rewrite the implementation of ESM::WheelPrefs.

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review195394

::: browser/app/profile/firefox.js:639
(Diff revision 4)
> -pref("mousewheel.with_shift.action", 2);
> +// only vertical wheel but want to scroll horizontally.  For such users, we
> +// should provide horizontal scroll with shift+wheel (same as Chrome).
> +// However, shift+wheel was used for navigating history.  For users who want
> +// to keep using this feature, let's enable it with alt+wheel.  This is better
> +// for consistency with macOS users.
> +pref("mousewheel.with_shift.action", 4);

ok, this is of course a change to the default behavior, but we do have some time to get feedback

::: dom/events/EventStateManager.cpp:3298
(Diff revision 4)
> -      // When APZ is enabled, the actual scroll animation might be handled by
> -      // the compositor.
> -      WheelPrefs::Action action;
>        if (pluginFrame) {
>          MOZ_ASSERT(pluginFrame->WantsToHandleWheelEventAsDefaultAction());
>          action = WheelPrefs::ACTION_SEND_TO_PLUGIN;

You change the ordering of whether action is first checked for plugin or apz, and delta is adjusted before the plugin chcek. But I guess that makes sense. But please test (manually) some Flash doing scrolling.

::: dom/events/EventStateManager.cpp:5915
(Diff revision 4)
>  
> -  *aOutMultiplierX = mMultiplierX[index];
> -  *aOutMultiplierY = mMultiplierY[index];
> +  // If the event should be treated as horizontal wheel operation, deltaY
> +  // should be multiplied by mMultiplierY, however, it might be moved to
> +  // deltaX for handling default action.  In such case, we need to treat
> +  // mMultiplierX and mMultiplierY as swapped.
> +  double multiplierForDeltaX = mMultiplierX[index];

We do have this similar code in several places.
Can you think of anyway to have a helper method to do this all? If not, fine.

::: dom/events/WheelHandlingHelper.h:233
(Diff revision 4)
> +  WidgetWheelEvent& mWheelEvent;
> +  double mOldDeltaX;
> +  double mOldDeltaZ;
> +  double mOldOverflowDeltaX;
> +  int32_t mOldLineOrPageDeltaX;
> +  bool mTreatedVertualWheelAsHorizontalScroll;

Vertually? Do you mean Virtually

        Attachment #8915954 -
        Flags: review?(bugs) → review+

    
    

    
  
Comment on attachment 8915954 [details]
Bug 143038 Make users can scroll contents horizontally with vertical wheel operation with a modifier

https://reviewboard.mozilla.org/r/186794/#review195394

> You change the ordering of whether action is first checked for plugin or apz, and delta is adjusted before the plugin chcek. But I guess that makes sense. But please test (manually) some Flash doing scrolling.

It's necessary to adjust the wheel deltas before updating wheel transaction which is automatically done in ComputeScrollTarget().

And unfortunately, I don't find Flash contents which have horizontal scroll. As far as I read Action Script documents, Action Script doesn't support horizontal wheel events. Therefore, Flash contents cannot handle horizontal scroll anyway. I don't know about the scrollable contents in Flash. That's what I could find.

> We do have this similar code in several places.
> Can you think of anyway to have a helper method to do this all? If not, fine.

Okay, I did it in new patch.

> Vertually? Do you mean Virtually

Oops! Nice catch!

    
    

    
      
  

    
    

    
  
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/63b547bb4078
Make users can scroll contents horizontally with vertical wheel operation with a modifier r=smaug

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/63b547bb4078
Status: ASSIGNED → RESOLVED
Closed: 7 years ago

          status-firefox58:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58

    
    

    
  
This add-on can be used until Firefox 58 has been released: Shift + Scroll (Horizontal Scrolling) - https://addons.mozilla.org/en-US/firefox/addon/shift-scroll/

    
    

    
  
(In reply to public from comment #128)
> This add-on can be used until Firefox 58 has been released: Shift + Scroll
> (Horizontal Scrolling) -
> https://addons.mozilla.org/en-US/firefox/addon/shift-scroll/

Firefox 56 and earlier, it can be implemented by XUL addons, but Gecko 58+ has this feature. So, only with Firefox 57, you cannot use this feature.

    
  
Depends on: 1438794

    
    

    
  
By navigating the source code, I believe I have figured out how to resolve bug 1438794 and would like to have a try to work on the "first good" bug for myself. Hope someone would assign bug 1438794 for me.
See Also:  → 1442141
Component: Event Handling → User events and focus handling

    
  
Regressions: 1570974

    
  
Regressions: 1633887

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: