The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla1.8beta5

Status

()

Core
Event Handling
--
minor
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Daniel Andrews, Assigned: Mark Mentovai)

Tracking

({fixed1.8, regression})

1.8 Branch
mozilla1.8beta5
PowerPC
Mac OS X
fixed1.8, regression
Points:
---
Bug Flags:
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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.
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.
(Reporter)

Comment 2

12 years ago
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.
what about firefox on the trunk? i wonder if something broke there in core code
or keybindings.
(Reporter)

Comment 4

12 years ago
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

12 years ago
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

12 years ago
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?

Comment 8

12 years ago
Confirming then.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 9

12 years ago
Scrolling bug.  Gotta have it.
Assignee: mikepinkerton → mark
(Assignee)

Comment 10

12 years ago
Created attachment 198829 [details] [diff] [review]
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.
Attachment #198829 - Flags: review?(bugs.mano)
(Assignee)

Comment 11

12 years ago
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.
(Assignee)

Comment 12

12 years ago
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
(Assignee)

Comment 13

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

What happened to my review request?

Oh.

(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+
(Assignee)

Comment 15

12 years ago
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+
(Assignee)

Comment 16

12 years ago
Fixed on trunk, along with additional Camino pref fixage.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

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

Alt/option-horizscroll should go the right way.
Attachment #198829 - Flags: approval1.8rc1?

Updated

12 years ago
Attachment #198829 - Flags: approval1.8rc1? → approval1.8rc1+

Updated

12 years ago
Flags: blocking1.8rc1? → blocking1.8rc1+
(Assignee)

Comment 18

12 years ago
Fixed on the branch.
Keywords: fixed1.8

Comment 19

12 years ago
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
(Assignee)

Comment 20

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

Comment 21

12 years ago
(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
You need to log in before you can comment on or make changes to this bug.