Closed Bug 31606 Opened 25 years ago Closed 24 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: 24 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: 24 years ago → 24 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.