Closed
Bug 21990
Opened 25 years ago
Closed 24 years ago
Sluggish keyboard scrolling
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: lee0, Assigned: waqar)
References
()
Details
When using the cursor keys to scroll a web page in the browser, scrolling does
not stop immediately after a key has been released. It instead continues
scrolling slower than expected.
The provided URL is a prime example, but the problem seems to be general over
all web pages.
Assignee: leger → joki
Component: Browser-General → Event Handling
QA Contact: leger → janc
Updated•25 years ago
|
Target Milestone: M16
Comment 2•25 years ago
|
||
I'm marking this one as works-for-me. Scrolling, even on Linux and even with
the keyboard, is damn fast these days (2000031516 build). Actually, the options
to change status seem to be gone in Bugzilla. Well: WORKSFORME
I'm using the 2000032309 Linux build, and the keyboard scrolling certainly is
sluggish. It's very fast if you use the mouse to drag the scroll bar, or use a
mouse wheel, but when using the keyboard I get exactly the effect that the
original reporter describes.
Comment 4•25 years ago
|
||
I think the reason keyboard scrolling is slower is that there is a repaint
triggered for every down-arrow worth of scrolling. I think the mouse-scrolling
may look at the current mouse position when there are a bunch of mouse events
accumulated.
Perhaps the keyboard scrolling needs to peek ahead in the key event queue or
something (if that's possible)?
This problem seems to have just gone away in recent builds.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 7•25 years ago
|
||
Reopening. I still see this in 2000-04-10-08-M15 Linux mozilla. It is
dependent on the painting performance on a given page. Short pages can usually
do a repaint in less than the key repeat time, and then this bug doesn't show
up. However, for longer pages, such as http://www.w3.org/TR/REC-CSS1 , this
bug still occurs.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
My apologies, then general problem has gone away with small/medium sized pages.
However, with the URL given, it is still a problem.
Comment 9•25 years ago
|
||
On the big table listed in http:
//www.people.fas.harvard.edu/~dbaron/tests/perftest this seems to be fixed for
scrolling up but not for scrolling down. Hmmm... it could be a paint
performance quirk...
Comment 10•24 years ago
|
||
Waqar, are you still handling linux layout issues? This seems to be more a
repainting problem than an event problem.
Assignee: joki → waqar
Status: REOPENED → NEW
Assignee | ||
Comment 12•24 years ago
|
||
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Assignee | ||
Comment 13•24 years ago
|
||
I have a fix for this.
Assignee | ||
Comment 14•24 years ago
|
||
Fix Checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 15•24 years ago
|
||
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Comment 17•24 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•