Closed Bug 293503 Opened 20 years ago Closed 19 years ago

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


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

1.8 Branch
Not set





(Reporter: wtmcgee, Assigned: mark)


(Keywords: fixed1.8, regression)


(1 file)

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

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.
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.
In the official releases (I tested .8.2, .8.3 and .8.4) control+ mousewheel right/left has the desired 

In the latest nightly builds, control + left/right does nothing, but option + right goes back, while option + 
left goes forward.
what about firefox on the trunk? i wonder if something broke there in core code
or keybindings.
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. 
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).
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.
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?
Confirming then.
Ever confirmed: true
Scrolling bug.  Gotta have it.
Assignee: mikepinkerton → mark
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.
Attachment #198829 - Flags: review?(bugs.mano)
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.
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.)
Component: Accessibility → Event Handling
Flags: review?(bugs.mano) → blocking1.8rc1?
Keywords: regression
Product: Camino → Core
Target Milestone: --- → mozilla1.8beta5
Version: unspecified → 1.8 Branch
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

What happened to my review request?


(shakes fist at Bugzilla)
Attachment #198829 - Flags: review?(bugs.mano)
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

r=mano, can't test this though.
Attachment #198829 - Flags: review?(bugs.mano) → review+
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

roc, can you sr the portion in libpref?
Attachment #198829 - Flags: superreview?(roc)
Attachment #198829 - Flags: superreview?(roc) → superreview+
Fixed on trunk, along with additional Camino pref fixage.
Closed: 19 years ago
Resolution: --- → FIXED
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

Alt/option-horizscroll should go the right way.
Attachment #198829 - Flags: approval1.8rc1?
Attachment #198829 - Flags: approval1.8rc1? → approval1.8rc1+
Flags: blocking1.8rc1? → blocking1.8rc1+
Fixed on the branch.
Keywords: fixed1.8
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.

Does your mouse have horizontal scroll capability?  History moved from option to
control with vertical scrolling.
(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. :)

Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.