scrolling by press-and-hold scrollbar arrow unusably slow on



18 years ago
13 years ago


(Reporter: ekrock's old account (dead), Assigned: Eric Vaughan)



Windows NT

Firefox Tracking Flags

(Not tracked)





18 years ago
On's list of local films playing, scrolling down by pressing and 
holding the scroll bar's down arrow is unusably slow (much more than 30x slower 
than 4.72).

Here was my test setup:
a) HW: HP Omnibook 4150 P2-300 w/ 256M memory
b) OS: WinNT 4.0 SP4
c) Nav4.72 and 3/1 Commercial (BuildID 2000022708--why diff from today's date?)

To repro:
1) open above URL in both browsers
2) close all tool bars
3) resize two browser windows to be same size
4) One at a time, in each window:
4a) start with the scroll bar all the way at the top
4b) Put the mouse pointer over the scroll bar's down arrow.
4c) Press and hold the left button and stopwatch time to reach bottom of page

I got these results:

Nav4.72: 2.98 sec.

3/1 Commercial (BuildID 2000022708): it scrolled agonizingly slowly, getting 
slower and slower, and I finally gave up at 90 seconds only part way down the 

1) This is *not* a DUP of bug 24956 ( scrolling 2x slower than 4.72 in 
Moz). The problems must be different because the performance gap between 4.72 
and 3/1 Commercial is orders of magnitude worse on than on
2) It's also not a DUP of bug 19476, which seems to be focusing on a reported 
flickering problem in scrolling (which I didn't see).


18 years ago
Keywords: perf

Comment 1

18 years ago
Reassigning to kevin for evaluation.
Assignee: beard → kmcclusk
It does scroll slower than usual for me on WINNT, but not as slow as ekrock is 
reporting. If I grab the thumb and scroll it is very responsive so it's not a 
rendering performance issue. My guess is that the repeating timer used to 
control scroll incrementing is falling behind.

Eric, can you take a look, since you implemented the gfxscrollbar button and 
repeat timers?
Assignee: kmcclusk → evaughan

Comment 3

18 years ago
I'm told this is because of style rule resolution. It should not be reresolving 
style for curpos, maxpos on scrollbars.
Target Milestone: --- → M15

Comment 4

18 years ago
*** Bug 31131 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
*** Bug 24956 has been marked as a duplicate of this bug. ***
See bug 25811.

Comment 7

18 years ago
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16

Comment 8

18 years ago
CCd myself. Eric, I just saw your comments from 2000-03-21 11:50 and I agree with 
you. Stop by or give me a call...

Comment 9

18 years ago
In a sense this comment is just noise, but I have to say this is probably my
number one issue with GFX scrollbars on the Mac.
They're slow as molasses on a G4 400MHz so I can only imagine what they're like 
on a slow machine (unless its purely a throttling issue).
This is with view manager 2. Switching back to native scrollbars cures the 

Comment 10

18 years ago
I no longer see the "unusably slow" bug on Commercial 5/5 2000050513 on WinNT4.0 
SP4. I retested on todays list of movies for theater #039 at 
Using the secondhard of my wristwatch, N6 seems just *barely* slower than 
Nav4.73 now on Win4.73 via click-and-hold scrolling using the scrollbar arrow. 
I'll doublecheck with my digital stopwatch at work, but I think this bug is 
either FIXED or darn close to FIXED.

Copied lordpixel's previous comment to the Mac-GFX performance bug which is 
where it should go.

Comment 11

18 years ago
It is better, but still slow.  moving to m18
Target Milestone: M16 → M18

Comment 12

18 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21

Comment 13

18 years ago
(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future'
Target Milestone: M21 → Future

Comment 14

17 years ago
Last Resolved: 17 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.