Closed Bug 48037 Opened 24 years ago Closed 11 years ago

Scrollbar sometimes follows mouse movement even with no buttons pressed

Categories

(Core :: XUL, defect, P3)

x86
All
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: torbjorn, Unassigned)

References

Details

(This bug report is for Mozilla M17, Build ID 2000080712, with Fullcircle. For 
some reason the only version I have to choose from above is "other". I'm 
posting this with IE because Mozilla crashed halfway through my first attempt.)

In some rare cases I've gotten myself into a situation where the rightmost 
scrollbar on the browser window follows the vertical movement of the mouse (as 
long as it's inside the browser window) even though none of the mouse buttons 
are depressed. I'm not sure what I did to provoke that, but I can trigger 
deliberately using the following steps:

1. Move the mouse pointer over to the slider, or whatever you call the movable 
part of the scrollbar, and keep it there.
2. Press and hold down the left mouse button.
3. Press and hold down the right mouse button. (A menu should pop up but ignore 
that.)
4. Release the right mouse button.
5. Move the mouse pointer outside the browser window.
6. Release the left mouse button.
7. Move the mouse pointer into the browser window. Move it up and down. The 
scrollbar should follow.

This works for horizontal scroll bars as well, though so far I've never 
triggered that accidentally.

I realize that this could very well be a feature of Windows rather than a 
Mozilla bug, but I've only seen it with Mozilla so far. The mouse is a simple 2-
button thing; a Logitech, according to the sticker underneath it. The Windows 
control panel only lists it as a "PS/2 Compatible Mouse Port". It's configured 
for right-handedness.
Sounds like a defect, but not one we have time to fix in current release.
->future
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Confirmed this also occurs under Linux. (someone should change the platform
field to all)


I just had something similar happen under linux with M18. I was scrolling when a
pop-up appeared (probably something like this host is unreachable, but I
dismissed it too quickly) moving the mouse pointer caused the scroll bar to
follow even though I was outside of the scroll area and not holding down any
mouse buttons
Yes, I get this regularly when an image/cookie acceptance prompt dialog comes
up.
Similar to bug 35191.
Yes, and whoever fixes this should also take into account this problem can also
happen when a dialog comes up while you are selecting a part of the URL bar. 
The selection continues to track mouse movement even after mouseup.  There seem
to be a lot of bugs in this area.
Blocks: 67277
->evaughan
Assignee: trudelle → evaughan
Status: ASSIGNED → NEW
I can repro this on build 2001061304 win98 as well.  You can actually reproduce
the bug in fewer steps than originally given.

1) Hold the left button while over the scrollbar.
2) Move cursor outside of Mozilla window.
3) Click the right mouse button.
4) Let the left button go.
5) Move cursor back inside Mozilla window --> scrolls with mouse movement.
*** Bug 88616 has been marked as a duplicate of this bug. ***
*** Bug 86285 has been marked as a duplicate of this bug. ***
*** Bug 91730 has been marked as a duplicate of this bug. ***
See also bug 72776, Right Click should cancel scrollbar thumb dragging 
operations.
*** Bug 112346 has been marked as a duplicate of this bug. ***
OS: All. This happens on Linux too, and probably Mac: bug 140563
OS: Windows 98 → All
*** Bug 148875 has been marked as a duplicate of this bug. ***
OS should be all
This happens on Mac OSX also
I can reproduce this by clicking on a link that won't work, grabbing the
scrollbar, then holding on to the scrollbar and moving it around while I wait
for the dialog box to pop up.  When it does pop up, I release the button. 
Moving the mouse around calls the window to scroll as if I was still clicking
(first only in the dialog, then when I dismiss the dialog anywhere).

The other ways to reproduce listed in this bug wouldn't work for me.

This is on Linux with 2002080902.
*** Bug 162883 has been marked as a duplicate of this bug. ***
I'm seeing this fairly regularly with Mozilla 1.1 + Orbit under Jaguar.

OSX, 10.2.1
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826

-Brett
Meh.  I'm now seeing it on the same computer, with a new build/modern theme.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021004
-Brett
Linux 2002102504. I was just going to file this bug, so I will add something I
noticed:

-It happens both with horizontal and vertical scrollbars, and TEXTAREAs, and
maybe some others objects.

-SELECTs work ok: the don't let the contextual menu to appear when the right
button is pressed while sliding the bar.

BTW, I saw this quip while searching: "No, really it is a feature! trust me!" :-)
Successfully repro'd with instructions in comment #9 on the following specs:

Mozilla 1.1 [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826]
Under Win98SE 4.10.2222 A

Additionally, this "sticky scrollbar focus" issue presents itself when:

1) the scrollbar is depressed
2) another application takes focus

I have seen this a lot with my comp, as I use a scheduler to get rid of a nag
screen (pauses download) in my newsreader when leaving it for long periods.  The
scheduler is calling to a DOS exe, but I have seen this issue with other (win32)
apps taking focus as well.

- DaRcAntiX
*** Bug 144954 has been marked as a duplicate of this bug. ***
*** Bug 187835 has been marked as a duplicate of this bug. ***
*** Bug 180409 has been marked as a duplicate of this bug. ***
Steps to reproduce from bug 180409:

1. Press left mouse button on the scrollbar handle
2. Drag the mouse into mozilla
3. Click right mouse button
4. Release left mouse button (outside popup menu)
I can replicate this bug by pressing left and right mouse buttons and holding
the mouse over the scroll block on the scroll bar but not always. I have managed
to get this fault with the Mozilla window maximised and have done it from within
the window as opposed to outside.

The effect can be cancelled by clicking on another part of the form. Looks like
a boolean value not resetting itself, to me.

I use a PS2 Tsunami Dolphin mouse 1100, Windows 98 upgrade, P166, 192mb ram, sis
chipset on jetway 530BF mainboard. Mozilla 1.3.1
Blocks: 220488
I has noticed a similar thing on Gallion (which I have not used in over a year)
and on all Mozilla 1.x.x. on Win and Lin. Although a "trivial" bug, using a
trackball I actually would vote for this to be a feature to keep and possibly
implement a easier way to activate it, since it allows you to smoothly scroll
using the just the ball, and a wheel is not needed.

For me the easiest way to activate it and avoid a context menu appearing on the
screen is:
1. Scroll to top of screen (using any method).
2. While on slider bar press left mouse button and move cursor into the region
near the mozilla "M" symbol.
3. With left mouse button still pressed and cursor over or near "M" press right
mouse button, then release both mouse buttons.
4. Move cursor back down into page display area and scroll away using the ball
(or by moving the mouse).
5. Click anywhere to cancel this mouse movement scrolling.

Instead of moving into the "M" region, you move into the display area, you also
get a context menu, which may or may not be in the way. But the scrolling works
the same on Linux. However, on win98 (all I have) with moz 1.5, this does not
activate scrolling (but moving to the "M" region still does).

A possible way to activate this in a more user friendly and less convoluted and
seemingly random manner might be to add a new item "Mouse Scroll" (possilly pref
enabled) to the right click activated context menu.
here's what I commented on bug 112403:
<<
Steps to reproduce scrolling without context menu:
1- Load a page long enough to have a vertical scroll bar
2- Left click on the scroll bar, then drag on the page. Keep the left button
pressed all the time.
3- Right click to bring context menu (no need to keep right button down).
4- Move the mouse over a disabled item (such as separator in the context menu)
then release the left button.
5- Right click on the scroll bar to remove the context menu.
6- Move the mouse up and down to scroll the page as if you were dragging the
scroll bar.

If it was only 1 step instead of 6 then I would use this feature a lot! Please
consider.
>>

my build id is 2004010808. the exact same thing happens on linux mozilla 1.5
I join comment #29 in the request for adding this feature to the gui.
*** Bug 220488 has been marked as a duplicate of this bug. ***
*** Bug 239165 has been marked as a duplicate of this bug. ***
confirmed w/ firefox 0.9.3. this bug really sux :(
Confirming that this bug is present in Mozilla 1.7.2 under FreeBSD 4.9 (X11R6
4.3.0,1).  Although, I can only get it to work following the instructions in
comment #30; I cannot make it exhibit this behaviour without the disabled
context menu item bit.

The same thing happens in gaim 0.81 as well.  Is this a bug in Mozilla or a bug
in the mouse reporting mechanisms of various window systems?
*** Bug 286626 has been marked as a duplicate of this bug. ***
Not seeing this in Forefox 1.0 final. Anyone else? Is this transferrable to
Seamknoey only, or is it still there too?
I also don't see this with firefox, but the reporter from bug 286626 did (w/
1.0.1).  Anyway, this is still the appropriate component, even if not the
appropriate product.
Assignee: eric → jag
I can still reproduce this on Firefox trunk nightly (2005-03-20), WinXP.
*** Bug 205889 has been marked as a duplicate of this bug. ***
*** Bug 288314 has been marked as a duplicate of this bug. ***
This and bug 29300 appear identical to me; mark that as a duplicate??

I've got a new way to reproduce this - and in Thunderbird (v1.0.2 currently) on
Windows XP, no less!

1. Compose a new message.
2. Switch back to the list of messages.
3. Click and drag some message (hold down the button for the rest of this).
4. Move to the Windows task bar and hover over the button for the message you're
composing.  This should bring it to the front.
5. Position the mouse at the top or bottom of the list of messages, in the main
window.  This should start the list scrolling.

Until you start dragging another message, the message list will continue scrolling.
i think this is fixed in 2.0?
This is still reproducible in 2.0. It was one of the first things I tried!
I have come to believe bug 353600 "[Modern Theme/Mac] Scrollbar tracks cursor after drag operation ends outside window" is a probably a duplicate of this bug.  I'm still seeing it in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061030 SeaMonkey/1.1b on a G3-800 iBook now running Mac OS X 10.4.8.  

The scenario I see is somewhat different and simpler than others I see here:

Reproducible: Always

Steps to Reproduce:
1. Open two browser windows, with the top one positioned to the left of the underlying window so that the space to the right of the top window is the underlying window.
1. Pull up a long web page in the top window.
2. Click on the scrollbar and drag it to scroll the window.
3. Drift the cursor to the right and release the button over the underlying SM window.  
4. Bring the cursor back over the top window.

Actual Results:  
When the mouse is released at step 3, the scrollbar remains highlighted.
When the cursor is brought back into the window, the scrollbar tracks it
anytime it is in the right portion of the window, resulting in unwanted scrolling.

Expected Results:  
When the button is released, scrolling operation should end.

Always happens in Modern theme.  Does NOT happen in Classic theme.  (So I thought it was a theme bug.)  Does not seem to happen if one releases over the desktop or another app.  Though I'm primarily using a trackpad, I have reproduced this using an IBM USB mouse.  Although I cited a browser example, it seems to happen with Mailnews and Chatzilla as well.  I could not reproduce this on my wife's XP laptop (last tested at SM 1.0.3 or .4)  

*** Bug 353600 has been marked as a duplicate of this bug. ***
(In reply to comment #44)
> ...
> The scenario I see is somewhat different and simpler than others I see here:
> 
> Reproducible: Always
> 
> Steps to Reproduce: ...

Mac G3 OSX 10.3.9

SeaMonkey 1.1.nightly
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre)
Gecko/20061220 SeaMonkey/1.1

I hereby confirm everything Rich Gray said in comment #44.
He hailed me on #seamonkey (rbgray) and walked me through it.


FIXED, it seems to me, comment #44, at least, using:
SeaMonkey 1.5a.Nightly
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre)
Gecko/20061221 SeaMonkey/1.5a

Eddie Maddox
Assignee: jag → nobody
Haven't seen this problem for years.  Anyone still having this problem?   I suggest this bug be closed.
I'm in no position to retest now,
but the latest dup is also very old.
Back in the day there were lots of
annoying funny things like this.
Seems like most of them got worked out somehow.
I can't reproduce this anymore the way I used to be able to. Like Eddie said, there were quite a few ways that thinks were screwy with scroll bars, but they don't appear to happen now. I'm in agreement to close it.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.