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.
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.
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Scrolling bug. Gotta have it.
Assignee: mikepinkerton → mark
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.
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?
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? Oh. (shakes fist at Bugzilla)
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.
Status: NEW → RESOLVED
Last Resolved: 14 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+
Fixed on the branch.
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
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. :) cl
You need to log in before you can comment on or make changes to this bug.