Closed Bug 31606 Opened 25 years ago Closed 25 years ago

scrolling by keys should stop immediately when key lifted

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 25054

People

(Reporter: dbaron, Assigned: waterson)

References

Details

(Keywords: perf)

DESCRIPTION: Scrolling by holding down keys (up arrow, down arrow, PgUp, and PgDn) should stop immediately when the key is lifted. Movement should not continue. STEPS TO REPRODUCE: * load http://www.w3.org/TR/REC-CSS1 * hold down the PgDn key for a second or two * lift the PgDn key ACTUAL RESULTS: * after the key is lifted, the page continues scrolling another four or five pages. EXPECTED RESULTS: * the page stops immediately when the key is lifted DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-03-10-13-M15 WORKS CORRECTLY ON: * Linux, NN 4.72
reassigning to saari as p4 for m17
Assignee: trudelle → saari
Priority: P3 → P4
Build 2000031516 i686-pc-linux-gnu (Linux 2.2.14, XFree86 4.0) demonstrates the expected behavior. Scrolling stops immediately when the keys are released. Suggest WORKSFORME.
Doesn't work for me in the build from 7 hours earlier...
Pav, didn't your event queue-like hacks fix this, or did you just cover mouse events?
Status: NEW → ASSIGNED
Target Milestone: M16
Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2
Target Milestone: M16 → M17
moving to m18
Target Milestone: M17 → M18
Pav has agreed to look at doing the same hack he did for mouse events to fix this for key events as well.
Assignee: saari → pavlov
Status: ASSIGNED → NEW
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
*** Bug 40779 has been marked as a duplicate of this bug. ***
*** Bug 45581 has been marked as a duplicate of this bug. ***
we're fast. using an optimized build on both linux and solaris, it stops immediatly.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
How fast we are depends on the page. Try http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSFrameConstructor.cpp There, I continue scrolling (on my PII-233) considerably longer than the amount of time I hold down the arrow key. What should really be happening is that we should be scrolling faster (according to some timer) -- If there are two down-arrow events in the event queue by the next timer tick, we should scroll two lines at once. Same for pages... Reopening, since it's not fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
ok, well.. that page is just stupid long. if we can't scroll fast enough to keep up with keypresses, then we have some other issues. waterson, could you please take a look at why scrolling this page sucks so much ass? didn't you say long pages were supposed to be faster? :)
Assignee: pavlov → waterson
Status: REOPENED → NEW
Keywords: perf
this is a dup of 25054
Yeah, dr is right. This is a dup. Let's open another bug if we want to investigate painting performance. *** This bug has been marked as a duplicate of 25054 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Verified dup of 25054.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.