Last Comment Bug 293503 - Side Scrolling + option's back/forward behavior is reversed
: Side Scrolling + option's back/forward behavior is reversed
Status: RESOLVED FIXED
: fixed1.8, regression
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: 1.8 Branch
: PowerPC Mac OS X
: -- minor (vote)
: mozilla1.8beta5
Assigned To: Mark Mentovai
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-09 11:21 PDT by Daniel Andrews
Modified: 2005-10-11 04:27 PDT (History)
6 users (show)
asa: blocking1.8rc1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fix mousewheel binding (3.33 KB, patch)
2005-10-07 12:37 PDT, Mark Mentovai
asaf: review+
roc: superreview+
asa: approval1.8rc1+
Details | Diff | Splinter Review

Description Daniel Andrews 2005-05-09 11:21:39 PDT
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) 2005-05-09 11:40:25 PDT
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 2005-05-09 12:14:28 PDT
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) 2005-05-09 12:20:08 PDT
what about firefox on the trunk? i wonder if something broke there in core code
or keybindings.
Comment 4 Daniel Andrews 2005-05-09 12:27:51 PDT
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 2005-05-09 16:18:30 PDT
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 2005-05-09 22:05:37 PDT
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) 2005-07-01 06:05:22 PDT
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 2005-07-06 01:21:48 PDT
Confirming then.
Comment 9 Mark Mentovai 2005-10-07 12:21:03 PDT
Scrolling bug.  Gotta have it.
Comment 10 Mark Mentovai 2005-10-07 12:37:12 PDT
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.
Comment 11 Mark Mentovai 2005-10-07 12:44:15 PDT
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 2005-10-07 16:25:29 PDT
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 2005-10-07 22:39:55 PDT
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

What happened to my review request?

Oh.

(shakes fist at Bugzilla)
Comment 14 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-10-09 11:18:00 PDT
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

r=mano, can't test this though.
Comment 15 Mark Mentovai 2005-10-09 12:57:21 PDT
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

roc, can you sr the portion in libpref?
Comment 16 Mark Mentovai 2005-10-09 23:06:26 PDT
Fixed on trunk, along with additional Camino pref fixage.
Comment 17 Mark Mentovai 2005-10-09 23:07:20 PDT
Comment on attachment 198829 [details] [diff] [review]
Fix mousewheel binding

Alt/option-horizscroll should go the right way.
Comment 18 Mark Mentovai 2005-10-10 17:18:39 PDT
Fixed on the branch.
Comment 19 Chris Lawson (gone) 2005-10-10 17:58:45 PDT
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 2005-10-10 22:31:50 PDT
Does your mouse have horizontal scroll capability?  History moved from option to
control with vertical scrolling.
Comment 21 Chris Lawson (gone) 2005-10-11 04:27:02 PDT
(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

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