Closed Bug 21990 Opened 25 years ago Closed 24 years ago

Sluggish keyboard scrolling

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

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
Updating QA Contact
Target Milestone: M16
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.
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)?
Bulk prioritizing bugs for correct milestones.
Target Milestone: M16 → M18
This problem seems to have just gone away in recent builds.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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.
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...
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
Looking into it
Status: NEW → ASSIGNED
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.
I have a fix for this.
Fix Checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
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
QA contact updated
QA Contact: gerardok → madhur
verified on build 2001-08-06-trunk
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.