293503 - Side Scrolling + option's back/forward behavior is reversed

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Daniel Andrews]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050507 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050507 Camino/0.8+


I have a Logitech MX1000 mouse, which has one of the mousewheels that scroll
sideways as well as the standard method.  One of my favorite things about this
is most browsers support some form of back/forward functionality (camino has
option+ right/left) to make browsing a snap.

Lately, and I'm not sure exactly when, I've noticed a reversal in the behavior.
 Option + right now goes back, and Option + left goes forward.  This is the
opposite of the expected behavior.  I've tested on the latest nightly as well as
.8.4, with the same result.

Reproducible: Always

Steps to Reproduce:
1.Using a mouse with side-scrolling capability, press option while pressing left
on the scroll wheel
2.
3.

Actual Results:  
If there is a page in the 'forward' cache, then Camino will go to that page. 
Otherwise, it will do nothing.  Pressing option + right will go 'back' to the
previous page.

Expected Results:  
The behavior should be reversed to match the back/forward paradigm in the
menubar.  option+ sidescroll left should go back, and option+ sidescroll right
should go forward, if possible.

Comment 1

[Mike Pinkerton (not reading bugmail)]

is there any way you could pinpoint when this broke? it seems strange that it
broke both on the trunk and 0.8.x at the same time.

Comment 2

[Daniel Andrews]

In the official releases (I tested .8.2, .8.3 and .8.4) control+ mousewheel right/left has the desired 
behavior.

In the latest nightly builds, control + left/right does nothing, but option + right goes back, while option + 
left goes forward.

Comment 3

[Mike Pinkerton (not reading bugmail)]

what about firefox on the trunk? i wonder if something broke there in core code
or keybindings.

Comment 4

[Daniel Andrews]

Firefox 1.0.3's behavior is a simple right/left wheel click invokes back/forward in the browser.  However, 
the latest Firefox nightly does not have this feature at all.   I tried option, control and command in 
conjunction with the mouse wheel, but none of these worked. 

So, you might be on to something. 

Comment 5

[Wevah (Nate Weaver)]

FWIW, Option+scrollwheel invokes back/forward in Camino, but it feels like it's
backwards here, too (scrolling down should go forward, not backward, IMHO). It's
possible that the mouse drivers simply make scrolling sideways perform a
Shift+scroll (since that scrolls horizontally in many, if not most, applications).

Comment 6

[Stuart Morgan]

FYI, the fact that Camino doesn't match Firefox for plain horizontal and option
up/down was done deliberately in bug 246879 and bug 244124, after Firefox was
changed in some very windows-centric ways.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Why is this still UNCO; it's a regression on the trunk, right?  We just don't
know when?

Or don't I understand something here?

Comment 8

[Jasper]

Confirming then.

Comment 9

[Mark Mentovai]

Scrolling bug.  Gotta have it.

Comment 10

[Mark Mentovai]

Attachment: Fix mousewheel binding

The binding for mousewheel.horizscroll.withaltkey is wrong in the core when
HORIZSCROLL_AVAILABLE is true.	The axis should be inverted, and sysnumlines
should be false.  This went wrong in bug 231718 (though the checkin comment
says 163215.)

The patch in camino gets rid of stuff that's no longer necessary now that the
defaults are correct in the core.

Comment 11

[Mark Mentovai]

Alt-horizscroll for history is backwards in Firefox and other products too.  My
Thinkpad doesn't behave happily with modifier-horizscroll, so I can't test on
Windows.  I'm not sure if this is a Windows limitation or if it's an IBM limitation.

Comment 12

[Mark Mentovai]

Core regression.  In Firefox 1.0, any horizontal scrolling action with or
without modifiers was bound to history, with left functioning as history-back
and right as history-forward.  Now, under HORIZSCROLL_AVAILABLE, only
alt-horizscroll is bound to history, but left and right are reversed.

(Camino regression, too.)

Comment 13

[Mark Mentovai]

Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

What happened to my review request?

Oh.

(shakes fist at Bugzilla)

Comment 14

[Asaf Romano (gone)]

Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

r=mano, can't test this though.

Comment 15

[Mark Mentovai]

Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

roc, can you sr the portion in libpref?

Comment 16

[Mark Mentovai]

Fixed on trunk, along with additional Camino pref fixage.

Comment 17

[Mark Mentovai]

Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

Alt/option-horizscroll should go the right way.

Comment 18

[Mark Mentovai]

Fixed on the branch.

Comment 19

[Chris Lawson (gone)]

This actually broke the back/forward abilities of the Kensington Turbo Mouse
entirely. (Not that I ever used this feature before stumbling across this bug,
but I thought it would be prudent to mention it.)

Before this patch, the mouse would do back/forward, but in reverse (the
behaviour considered to be a bug). Now it won't do anything when I hold option
-- it just scrolls the page normally, as though I had never held any modifiers.

cl

Comment 20

[Mark Mentovai]

Does your mouse have horizontal scroll capability?  History moved from option to
control with vertical scrolling.

Comment 21

[Chris Lawson (gone)]

(In reply to comment #20)
> Does your mouse have horizontal scroll capability?  History moved from option to
> control with vertical scrolling.

Yes. As I said before, it worked until this patch was checked in, albeit
backwards. Now it doesn't do anything at all.

Oddly enough, though, now the control key does what the option key used to do,
except not backwards. So perhaps this was a false alarm. :)

cl