Closed Bug 157123 Opened 22 years ago Closed 14 years ago

Browser scrollbars continue scrolling after I release mouse button

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Version:
1.4 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.5beta

People

(Reporter: bugzilla, Unassigned)

References

Details

(Whiteboard: [closeme 2010-10-25])

Attachments

(2 files)

nsRepeatService patch for the trunk
1.81 KB, patch
bnesse
: review+
scc
: superreview+
scc
: approval+
Details | Diff | Splinter Review
nsRepeatService patch for the branch
700 bytes, patch
bnesse
: review+
scc
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1a+) Gecko/20020711
BuildID:    2002071108

If I click and hold the mouse pointer over any of the scroll buttons (up, down,
left, right) in Navigator, and leave the pointer over the arrow, then the window
continues scrolling for a few seconds.

Reproducible: Always
Steps to Reproduce:
1. Open Navigator to a long page.
2. Scroll down using scroll buttons (not mouse wheel).
3. Release mouse button.

Actual Results:  Page continued scrolling after I released the mouse button.

Expected Results:  Scrolling should have stopped.
-> Xp Toolkit
Assignee: Matti → jaggernaut
Component: Browser-General → XP Toolkit/Widgets
QA Contact: asa → jrgm
Although there are various open bugs on this, some dating back 2 years [bug
29300], I have just started seeing this on recent branch builds. This is
*incredibly* annoying and should be, IMO, an RTM blocker.
It does seem to be new to recent builds (I see it on 2002071703 for Mac OS X).
Probably unrelated, but I did see it on earlier builds of Chimera (it's fixed
there now). 
*** Bug 158693 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Whiteboard: [adt3 RTM]
Whiteboard: [adt3 RTM] → [adt3 RTM] [driver:scc]
my guess is that the magic derives from <binding id="autorepeatbutton"
extends="chrome://global/content/bindings/scrollbox.xml#scrollbox-base">
and that there's a timer somewhere which needs to be killed onmouseup, but i
can't find the timer. hewitt?
Assignee: jaggernaut → hewitt
*** Bug 158973 has been marked as a duplicate of this bug. ***
*** Bug 158832 has been marked as a duplicate of this bug. ***
I just noticed this also affects the gray scroll area, not just the scroll
arrows. Try going to a long page like this:
http://bugzilla.mozilla.org/show_bug.cgi?id=97284 and click in the gray so as to
scroll down one screen. So far so good - now hold the mouse down for a second,
and  let go. The window will keep scrolling until the box hits the mouse or you
move the mouse away from the scroll bar. 

I'm still on build 2002071703 - I'll download a new build tomorrow and see if
it's there too. 
I confirm that the gray scroll area is also affected in build 2002072203
This is a duplicate of bug 157837. I don't know which bug to dupe to which however.
*** Bug 159219 has been marked as a duplicate of this bug. ***
IMHO, this is NOT a dupe of <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=157837">Bug 157837</a>.  This
is the opposite of that bug:  here the scrollbar keeps going after you let go;
there it never starts.
You appear to be correct. It seems I didn't read bug 157837 carefully enough.
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3 RTM] [driver:scc] → [adt2] [driver:scc]
Can we get some action on this bug?
It would help if someone could spend some time to figure out when this started,
or when it became more prominent. It seems like the bug's been there for a
while, but is much more visible now.
So, after some experimentation, it turns out that this bug appears to be very
reproducable on the TiBook 500Mhz (Rev 1) machines, and much less so (not at all
for sfraser and myself) on faster desktop machines. It also turns out that this
is hard to reproduce on the TiBook with a debug build (though a small amount of
lag is visible.)

I believe that this is releated to the frequency of the timer that is being used
to send mouse clicks to the scroll control. It appears that we are "queuing up"
timer calls waiting to be serviced while the mouse is down. After the mouse is
released, we process the events until the "queue" is empty. Other platforms use
a frequency of 50ms, for some reason the Mac uses 10ms. Increasing the delay on
the timer appears to have decreased the visible "lag" in my debug build. I am
building a non-debug build to test this theory.
i sure did....*two years ago*!
Changing the timer interval to 25ms appears to "fix" this. The downside to this
is that it slows scrolling somewhat.

Some sample (non scientific) test results:
scrolling a reasonably long page (http://www.w3.org/MarkUp/)
10ms timer -> 20 sec.
25ms timer -> 24 sec.
50ms timer -> 34 sec.

scrolling an unreasonably long page (http://www.ietf.org/rfc/rfc1866.txt)
10ms timer -> 2 min. 39 sec.
25ms timer -> 3 min. 04 sec.
50ms timer -> 4 min. 27 sec.
(Win2k) 50ms timer -> 3 min. 40 sec.

Note that the differential between the 10ms and 25ms timer is fairly small
because the 10ms timer is basically running as fast as it can.

The problem is that the minimum firing interval on this timer will, as with all
timers, be machine dependent.
Note that this is different from bug 29300. That bug describes the 'sticky
mouse' problem, where we think the mouse is still down after you've released the
button, and things stay like that forever until you click again. If this happens
in the scroll thumb, moving the mouse will cause scrolling.

This bug is a little different. Here, after click-holding on the scroll arrow
for some amount of time, then releasing, we keep scrolling for some period of
time, but then stop. Also, this affects the scroll arrows, but not dragging the
scroll thumb.
I think this is yet more fallout from our WaitNextEvent tweaking. If I set the
WNE sleep time to 0, the problem goes away.

The problem seems to be that we don't handle the mouseup event quickly enough;
WNE seems content to sleep for 5 ticks before giving us this event (unless you
move the mouse). And EventAvail() doesn't return true even if a mouse up is
pending, it  seems.
If the mouse is down, we pass 0 as the sleep time to WNE. Brian did say that if
you pass 0 as the sleep time to WNE, the event mgr replaces it with some random
value to disuade peple from using 0. I wasn't convinced that was true based on
measuring CPU usage of our app when the mouse was down (always near 100%) but,
it's worth mentioning.
> If the mouse is down, we pass 0 as the sleep time to WNE

Right, but as soon as you release, we back off to 5 ticks. My old 'IsBusy' model
had some deliberate lag built in so that we behaved busy for a second after
going idle, which avoided rapid oscillations between busy and idle states, and
also prevented mouseup issues.
Shudder, flinch. So, if we reverted to that model, embedding apps would have to
as well?
OK, If that's really the only way around this in our WaitNextEvent world, I
could make BrowserIsBusy() available in the EmbedAPI static lib. Now that we
have decided to drop support for OS9, let's see if we can avoid this by using
Carbon Events and not ever have to calculate sleep time. The patch I have for
using Carbon Events for processing the PLEvent queue is a step in that direction.
Some printfs show that EventAvail() seems to return false even when a mouseup is
pending. Maybe we need to look ahead in the event queue, or use WaitMouseUp(),
or something.
If support for OS 9 is dropped why stay with Carbon?   If we don't have to deal
with OS 9 compatibility issues then just use Cocoa.   Cocoa apps seem to handle
better on OS X anyway.  Apple's Cocoa system allows fairly easy transfer from a
Unix/X11 app to Mac OS X.   Plus Cocoa apps have a built-in spellchecker, font
chooser, color picker, etc.    
   Why are we dropping OS 9 support?  Users that don't upgrade from 9 to X will
be forced to look for a different browser (or just stay with their old build).
A little more testing also shows that removing the call to WakeUpProcess() in
macthr.c also fixes this bug... see bug 158927 and bug 139802 for more on this.
This patch changes the timer interval for Mac OS 9 and Mac OS X from 10ms to
25ms, and converts the timer to a repeating timer (which is just a
cleanup/efficiency change). Changing the timer interval has little effect on
scrolling speed, since we're gated by the speed at which we redraw anyway.
This patch just changes the timer interval for Mac OS 9 and Mac OS X from 10ms
to 25ms
Taking. Reviews please.
Assignee: hewitt → sfraser
Comment on attachment 93650 [details] [diff] [review]
nsRepeatService patch for the trunk

Wow, that looks just like the one I did, except I used mFirstTime... :)
I assume there is a nsRepeatService.h component to this too? ;)

One additional change I'd suggest to eliminate confusion:
Index: mozilla/layout/xul/base/src/nsSliderFrame.h
===================================================================
RCS file: /cvsroot/mozilla/layout/xul/base/src/nsSliderFrame.h,v
retrieving revision 1.36
diff -u -2 -r1.36 nsSliderFrame.h
--- mozilla/layout/xul/base/src/nsSliderFrame.h 14 Nov 2001 01:33:08 -0000     
1.36
+++ mozilla/layout/xul/base/src/nsSliderFrame.h 2 Aug 2002 02:12:26 -0000
@@ -53,7 +53,4 @@
 class nsSliderFrame;

-#define INITAL_REPEAT_DELAY 500
-#define REPEAT_DELAY	     50
-
 nsresult NS_NewSliderFrame(nsIPresShell* aPresShell, nsIFrame** aResult) ;

with or without that. r=bnesse.
Attachment #93650 - Flags: review+
Comment on attachment 93651 [details] [diff] [review]
nsRepeatService patch for the branch

I'm inclined to want the full trunk patch here too, but this covers the real
issue. r=bnesse.
Attachment #93651 - Flags: review+
Comment on attachment 93650 [details] [diff] [review]
nsRepeatService patch for the trunk

sr=scc
Attachment #93650 - Flags: superreview+
Comment on attachment 93650 [details] [diff] [review]
nsRepeatService patch for the trunk

a=scc (on behalf of, and after discussion with drivers) for checkin to the
mozilla trunk for 1.1
Attachment #93650 - Flags: approval+
Comment on attachment 93651 [details] [diff] [review]
nsRepeatService patch for the branch

sr=scc
Attachment #93651 - Flags: superreview+
Keywords: adt1.0.1, mozilla1.0.1
Target Milestone: --- → mozilla1.0.1
Whiteboard: [adt2] [driver:scc] → [adt2]
Comment on attachment 93651 [details] [diff] [review]
nsRepeatService patch for the branch

Approved for branch; change mozilla1.0.1+ to fixed1.0.1 when checked in.
Attachment #93651 - Flags: approval+
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check
this in asap, then replace "mozilla1.0.1+" with "fixed1.0.1". thanks!
Blocks: 143047
Keywords: adt1.0.1 → adt1.0.1+
Attachment 93650 [details] [diff] checked in on the TRUNK (with bnesse's cleanup suggestion).
Attachment 93651 [details] [diff] checked in on the BRANCH.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla1.0.1+ → fixed1.0.1
Resolution: --- → FIXED
Looks like this caused bug 160824. Because we're short on time and need all the
testing we can get I've asked that it be backed out so that folks can test
without crashing.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
trunk patch backed out, it caused crasher bug 160824
backed out of branch too
The branch fix (attachment 93651 [details] [diff] [review]) simply changed the timer interval #ifdef
XP_MAC, so there was no need to back that out. The trunk crasher (bug 160824)
must have been caused by the changes to the timer behaviour.

Can request that attachment 93651 [details] [diff] [review] be allowed back on the branch please?
This is what went into the branch:

Index: mozilla/layout/xul/base/src/nsRepeatService.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/xul/base/src/nsRepeatService.cpp,v
retrieving revision 1.19.28.1
retrieving revision 1.19.28.2
diff -b -u -2 -r1.19.28.1 -r1.19.28.2
--- mozilla/layout/xul/base/src/nsRepeatService.cpp	10 Apr 2002 03:01:21 -0000
1.19.28.1
+++ mozilla/layout/xul/base/src/nsRepeatService.cpp	2 Aug 2002 22:21:21 -0000
1.19.28.2
@@ -47,5 +47,5 @@
 #if defined(XP_MAC) || defined(XP_MACOSX)
 #define INITAL_REPEAT_DELAY 250
-#define REPEAT_DELAY        10
+#define REPEAT_DELAY        25
 #else
 #define INITAL_REPEAT_DELAY 250

Patch in attachment 93651 [details] [diff] [review] has been recommitted onto the branch, and checked into
the trunk. I filed bug 160926 to clean up the timer usage, as I attempted to do
in attachment 93651 [details] [diff] [review]. Marking bug fixed again.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
thanks simon.  I for one, cannot use the app on my powerbook without this fix.
*** Bug 161093 has been marked as a duplicate of this bug. ***
The current patch alleviates the bug but does not fix it, and I think as
processor speeds increase this will become more apparent. 

To see it now, go to a page that slows Mozilla down, like this:
http://www.bbc.co.uk/dna/h2g2/classic/U189267

then click and hold on a scroll bar or arrow, and you'll see the behavior is
mostly unchanged. 
*** Bug 161616 has been marked as a duplicate of this bug. ***
jrgm: pls verify this as fixed on the 1.0 branch, then replace  "fixed1.0.1"
with "verified1.0.1". thanks!
Whiteboard: [adt2] → [adt2] [ETA 08/03]
*** Bug 174088 has been marked as a duplicate of this bug. ***
I'm seeing this happen again in 1.2, not as bad as before, but definitely
happening. The arrow buttons themselves seem fine but the problem still shows in
the gray scroll area. Try it on this page by scrolling to the very top, then
holding down the mouse button near the bottom of the scroll bar (in the gray
region, not the button). The page continues to scroll a few more screens after
releasing the mouse button. You might have to try it a few times to get a real
feel for it, since it seems to vary from time to time. 
> I'm seeing this happen again in 1.2, not as bad as before, but definitely
happening.

Me too. Seems to happen on slower machines. Happens on an original iBook very
often, an iBook2 very infrequently, and never on my G4 machines.
Just checked and found that this is 100% reproducible using Mozilla 1.2.1,
Modern skin, on orig iBook. Under same conditions, cannot repro on Classic skin.
Yup, I see it on my G4500 but only in the modern skin. Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla1.4alpha
*** Bug 193050 has been marked as a duplicate of this bug. ***
Seems that what I see with 1.3b (and older) is related to this bug:
On long pages, clicking into the grey area below or above the scrollbar
slider always (at least for the lower area) jumps twice, making it 
impossible to use the jump feature to scroll window by window through a
page.
It does not happen on all pages (e.g., not on this one).
I also saw the old original bug with 1.3b just a few minutes ago when 
scrolling up and down <http://www.rpbourret.com/xml/NamespacesFAQ.htm>
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
*** Bug 163502 has been marked as a duplicate of this bug. ***
Still present in 1.4a. Sometimes, Mozilla always jumps twice when clicking into 
the grey area below or above the slider, now even on this page, sometimes it
just decides to work correctly. I've not seen the continuous scrolling yet again.
Target Milestone: mozilla1.5alpha → mozilla1.5beta
Well, its about 4.5 yrs later than some of these reports, and IM on version 2.0.0.9, and Im experiencing this 'sticky mouse' behavior, as if the mouse buttons wont give up their scroll bar focus, even though they are both in their 'up' position.  Im new to mozilla, but not to computing.  I dont know if there is some way I should continue this bug report, or start  a new one since so much time has lapsed since it was first reported.
Re-opened for Firefox 3 on Windows Vista SP1 at

https://bugzilla.mozilla.org/show_bug.cgi?id=424815
Assignee: sfraser_bugs → nobody
Status: ASSIGNED → NEW
(In reply to comment #63)
> Re-opened for Firefox 3 on Windows Vista SP1 at
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=424815

and bug 424815 was duped to fixed Bug 421486 - automatic unwanted scrolling for no reason, due to scroll arrow/bar interaction

so it is now working for you in FF?
Whiteboard: [adt2] [ETA 08/03] → [closeme 2010-10-25]
QA Contact: jrgmorrison → xptoolkit.widgets
Closing as fixed again since:
- Patches have landed on trunk in this bug already (yonks ago).
- Other than comment 62, no reports on anything newer than Firefox 2.0
- Comment 63 has been resolved separately in bug 424815 -> bug 421486.
- Past whiteboard closeme date and no new replies.
Status: NEW → RESOLVED
Closed: 22 years ago → 14 years ago
Resolution: --- → FIXED
Version: Trunk → 1.4 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: