Open
Bug 71464
Opened 24 years ago
Updated 2 years ago
Using the scrollwheel above the horizontal scrollbar should scroll horizontal, not vertical
Categories
(Core :: XUL, enhancement, P5)
Tracking
()
NEW
People
(Reporter: spark, Unassigned)
References
Details
As said in summary, it would be need to be able to scroll the windows horizontal
using the mousewheel above the horizontal scrollbar. I guess there as no
disadvantage in doing so and all good toolkits that I know (i.e. Gtk and Qt) do
it this way. I don't know about the Win32 Toolkit.
Comment 1•24 years ago
|
||
->bryner/p5/future
Assignee: trudelle → bryner
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → Future
Comment 2•24 years ago
|
||
Haven't been able to find anything in Win2000 that does this. Native scrollbars
definitely don't. But that's not to say it's a bad idea.
Comment 3•24 years ago
|
||
Would be nice, but strikes me as somewhat difficult compared to the benefit.
Status: NEW → ASSIGNED
Comment 4•24 years ago
|
||
TextPad 4.4 on windows 2000 does just that.
Comment 5•24 years ago
|
||
I want this feature even if using a modifier key.
e.g. shift + mouse wheel
I'd like both. Optionally (because in some cases it can be annoying) scroll
horizontally while hovering over a horizontal scrollbar, and option to scroll
horizontally as mousewheel action in prefs. The usual behavior is up=right,
down=left (think X, Y values from algebra).
I will note that this behavior is not expected of Windows programs, it is only
supported in apps that have adaptive code written in. Not even IE5.5 appears to
support this; this would be a great place to have the advantage.
Actually, the behavior in Textpad seems to be the opposite of what I thought.
Maybe this should be an option too. Something like "reverse horizontal action"
with the default being the same as Textpad.
Comment 8•23 years ago
|
||
Seems to me that it would make more sense for scrolling down on the wheel to
move right on the page; page content goes left to right, as they do up to down.
That way, scrolling down always progresses further into your content and up
always takes you back.
Comment 9•23 years ago
|
||
*** Bug 129384 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
Related, but different bug: Bug 143038 (using a modifier key instead of hover).
Comment 11•20 years ago
|
||
(In reply to comment #2)
> Haven't been able to find anything in Win2000 that does this. Native scrollbars
> definitely don't. But that's not to say it's a bad idea.
Opera 7 is a good example. I would like to see this added as an option, together
with bug 143038.
Comment 12•20 years ago
|
||
(In reply to comment #3)
> Would be nice, but strikes me as somewhat difficult compared to the benefit.
>
Actually it is not difficult at all, you need something like this:
-- begin code snippet #1 --
if (uMsg == WM_NCHITTEST) { // test for non-client window area hit
// allow default window procedure to handle it first
LRESULT rv = DefWindowProc(hWnd, uMsg, wParam, lParam);
if (rv == HTHSCROLL) { // if horizontal scroll bar hit
// set some global variable accordingly
g_WheelDirection = WHEEL_HORIZONTAL;
} else {
g_WheelDirection = WHEEL_VERTICAL;
}
return rv;
}
-- end code snippet #1 --
And also something like this (note that the code can be simpler, this handles
Ctrl key as a modifier for the scroll amount as well):
-- begin code snippet #2 --
if (uMsg == WM_MOUSEWHEEL) {
WORD Keys = GET_KEYSTATE_WPARAM(wParam);
int zDelta = GET_WHEEL_DELTA_WPARAM(wParam);
int Lines = abs(zDelta / WHEEL_DELTA);
WORD wScrollNotify = 0xFFFF;
UINT uMessage;
// test the above mentioned global variable
if (g_WheelDirection == WHEEL_VERTICAL) {
uMessage = WM_VSCROLL;
if (zDelta > 0) {
if (Keys == MK_CONTROL) {
wScrollNotify = SB_PAGEUP;
} else {
wScrollNotify = SB_LINEUP;
}
} else {
if (Keys == MK_CONTROL) {
wScrollNotify = SB_PAGEDOWN;
} else {
wScrollNotify = SB_LINEDOWN;
}
}
} else {
uMessage = WM_HSCROLL;
if (zDelta > 0) {
if (Keys == MK_CONTROL) {
wScrollNotify = SB_PAGELEFT;
} else {
wScrollNotify = SB_LINELEFT;
}
} else {
if (Keys == MK_CONTROL) {
wScrollNotify = SB_PAGERIGHT;
} else {
wScrollNotify = SB_LINERIGHT;
}
}
}
// send yourself the right message
if (wScrollNotify != 0xFFFF) {
for (int i = 0; i < Lines; i++) {
SendMessage(g_hWndView, uMessage, MAKELONG(wScrollNotify, 0), 0L);
}
}
return 0;
}
-- end code snippet #2 --
If you need any additional info let me know by email.
Igor
Comment 13•20 years ago
|
||
Gtk behaviour is down scrolls to the right, which is consistent with reading
order. This bug is a problem of feeling native, too.
See bug 176548, which seems to be the same with the only difference that
proposed solution is to use gtk widgets.
Comment 14•20 years ago
|
||
(In reply to comment #13)
> Gtk behaviour is down scrolls to the right, which is consistent with reading
> order. This bug is a problem of feeling native, too.
That would be fine with me. Opera also does this (down scrolls to the right). I
just gave quick code example how it should be done natively in Windows. Just
reverse the condition.
> See bug 176548, which seems to be the same with the only difference that
> proposed solution is to use gtk widgets.
I have seen it -- seems to me that you have accidentaly posted the wrong number.
To me it doesn't seem related to this bug.
Moreover, related to bug #143038 I agree about having Ctrl+wheel shortcut for
Zoom +/- like in Photoshop and Opera, but I believe that having modifier keys
for changing scroll direction is somehow inconsistent with good UI design. Hover
is more intuitive and if you already reach to press additional key you may as
well use left/right arrow for horizontal scrolling instead of wheel.
Please someone enlighten me -- why use gtk under windows for this feature if
native solution is so simple?
Comment 15•20 years ago
|
||
(In reply to comment #14)
> > See bug 176548, which seems to be the same with the only difference that
> > proposed solution is to use gtk widgets.
> I have seen it -- seems to me that you have accidentaly posted the wrong number.
> To me it doesn't seem related to this bug.
Sorry, I meant bug 176458.
> Please someone enlighten me -- why use gtk under windows for this feature if
> native solution is so simple?
I had linux in mind. As far as linux is concerned default builds use gtk2 so
this should not be a problem - only events seem to be hijacked by mozilla.
I think bug 176458 is about fixing the bug for linux, and this one is about a
cross platform enhancement. I'm voting for both.
Comment 16•20 years ago
|
||
(In reply to comment #15)
> Sorry, I meant bug 176458.
No problem. I wasn't aware that this issue exists in Linux version of Firefox too.
> I had linux in mind. As far as linux is concerned default builds use gtk2 so
> this should not be a problem - only events seem to be hijacked by mozilla.
> I think bug 176458 is about fixing the bug for linux, and this one is about a
> cross platform enhancement. I'm voting for both.
If I understand correctly this bug # is about making the feature available for
Winodws version of the browser. I have tried to contribute native solution but
it seems that the developers do not care too much (please correct me I am being
overly mild in expressing myself).
Comment 17•20 years ago
|
||
*** Bug 176458 has been marked as a duplicate of this bug. ***
Comment 18•19 years ago
|
||
(In reply to comment #16)
>...
>
> If I understand correctly this bug # is about making the feature available for
> Winodws version of the browser. I have tried to contribute native solution but
> it seems that the developers do not care too much
I don't see anything in this bug that supports this conclusion.
In any event, team up with Ryner or assign the bug to yourself, attach a patch
and mark it for review - see what happens with it.
Updated•18 years ago
|
Assignee: bryner → jag
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.widgets
Target Milestone: Future → ---
Comment 22•17 years ago
|
||
This is the behavior of various GTK+ applications, don't know if it is an actual behavior of GTK+ itself.
Flags: blocking1.9?
Comment 23•17 years ago
|
||
I'll not agree with you.
EVERY horizontal scrollbar can be used with scrollwheel.
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9-
Comment 24•17 years ago
|
||
Has there been any progress on this? Scrolling above any scroll-bar should activate that scroll-bar under GTK, so scrolling over a horizontal scroll-bar should scroll horizontally.
Current behaviour is inconsistent with all other GTK2 applications.
Updated•16 years ago
|
Assignee: jag → nobody
Comment 26•15 years ago
|
||
This is clearly a bug since the scroll bar is not catching events when mouse is over it. Even clicking on the scroll bar does not make it catch mouse scroll events afterwards.
This bug is now old enough to be wearing long trousers , any chance of something like the code posted in #12 getting applied?
Comment 27•13 years ago
|
||
Hello Bugzilla.
My issue is happening since Firefox 4.0, OS: windows xp.
Optical 4D Mouse A4Tech WOP-35: [url]http://www.a4tech.com/product.asp?cid=1&scid=8&id=22[/url]
Since Firefox 4, the Horizontal wheel doesn't works properly, this duplicates the function of the vertical wheel; ie, the Horizontal wheel scrolls vertically, although "horizontal navigation bar" appears on screen.
Nevertheless, the horizontal-wheel worked properly until FF3.6.x.
But, not only that. The horizontal wheel no longer works to navigate through facebook pictures, iimmgg.com images (on galleries), or similar web, how it worked before, until FF3.6 :cry:
I have enabled: the enhanced dual wheel mode, in the last driver installed (v7.80).
And I tried with a new firefox profile, and its safe mode. But the issue persists.
Comment 28•13 years ago
|
||
Mozillazine forum, unsolved topic:
http://forums.mozillazine.org/viewtopic.php?p=10762037#p10762037
Comment 29•13 years ago
|
||
This is still not working on firefox 12 Linux version
Comment 30•9 years ago
|
||
So this bug is already 14 years old and nobody has fixed it nor stated a reason to close it.
This behavior is specially annoying for mouse users because in addition to not being able to scroll on the horizontal scrollbar, shift+scroll doesn't work for this as it does in most programs, so the only way to scroll horizontally is either clicking on the bar or using the auto-scroll, which doesn't give you as much control and precision as the scrollwheel provides.
Is there any reason this behavior shouldn't be implemented? If so, would it be possible to get it as an addon?
PS: Could someone please develop this as an addon (if possible)? I'm not a developer.
Comment 31•8 years ago
|
||
Hi cousteau and blog.
The extension or addon to Firefox, that improves the performance without being automatic scrolling is: "Scrollbar Anywhere".
Since Gnu/Linux distros if working my horizontal whell as expected. Nevertheless, not the Automatic Scrolling on whole system.
Comment 32•8 years ago
|
||
(In reply to Turson from comment #31)
> "Scrollbar Anywhere".
Not exactly what I wanted. Nevertheless, I've found another extension, "Horizontal Scroll", that does exactly what is being requested. Finally!
Comment 33•8 years ago
|
||
thanks Cousteau !
That finally provides a workaround to fix this bug and got it noticed here. Many thanks for the heads up.
Maybe one day it will be integrated in FFx.
Comment 34•7 years ago
|
||
Scrollbar Anywhere (2013-12-28) by babicvlatko
<https://addons.mozilla.org/en-US/firefox/addon/ScrollbarAnywhere/>
Horizontal Scroll (2016-10-02) by def00111
<https://addons.mozilla.org/firefox/addon/horizontal-scroll/>
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•