Arrow-key scrolling slow and key-presses "queue up" which is annoying




19 years ago
10 years ago


(Reporter: I.Clarke, Unassigned)


({perf, topembed-})

perf, topembed-

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbetadenied], T2, URL)



19 years ago
When using the arrow keys to scroll in the main browser window, if the keys are
pressed too frequently, they will "queue up".  This means that the window will
continue to scroll for a while after you have finished pressing the arrow key
which can be most irritating.

Comment 1

19 years ago
If you hold down an arrow key, have the auto-repeat set to a very high rate,
and either slowdowns in the current app or general system bog slows down
the current app enough so that it can't keep up, this can happen on with app.

This is a real-world performance problem, but not one that can likely be
assigned to any specific engineer. OTOH, as other performance problems get
fixed, this should get better as a result.

Adding perf keyword just so this will get looked at before shipping.
Keywords: perf
QA Contact: nobody → elig

Comment 2

19 years ago
I *think* this goes to Nisheeth. Thanks, Sean!
Assignee: nobody → nisheeth

Comment 3

19 years ago
Don, you hold general browser bugs like this, right?  Please re-assign this to 
the right person if you don't.  Thanks.
Assignee: nisheeth → don

Comment 4

19 years ago
Doh. So this isn't due to Gecko infrequently doing frame updates, then?

Comment 5

19 years ago
Chris, find out who really owns this ... maybe you? :-)
Assignee: don → mcafee
Target Milestone: M15

Comment 6

19 years ago
can we get it before beta1?
Keywords: beta1

Comment 7

19 years ago
Whiteboard: [PDT-]

Comment 8

19 years ago
Move to M16 for now ...
Target Milestone: M15 → M16


19 years ago
Target Milestone: M16 → M18

Comment 9

19 years ago
Move to M20 target milestone.
Target Milestone: M18 → M20

Comment 10

19 years ago
Nominating for nsbeta3; this is the sort of general performance problem that
should get evaluated to see how much of a problem remains after the first full 
round of more specific performance fixes.
Keywords: beta1 → nsbeta3
Whiteboard: [PDT-]

Comment 11

19 years ago
over to saari for a look.
Assignee: mcafee → saari

Comment 12

19 years ago
I don't see this bug on linux anymore, which isn't surprising since I think
pavlov fixed it a while ago by dropping events.

Comment 13

19 years ago
seems much better now, nsbeta3-
Whiteboard: [nsbeta3-]
Target Milestone: M20 → Future

Comment 14

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

Comment 15

18 years ago
This works for me
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 16

18 years ago
Platform: PC
OS: Red Hat 6.2 (Linux 2.2.14)
Mozilla: 2000101212 M18 Trunk Build

Marking as Verified.

Comment 17

18 years ago
*** Bug 52391 has been marked as a duplicate of this bug. ***
Reopening since bug 52391 is now a duplicate of this one. Transferring
component, keywords, cc list, qa contact (since elig is gone), severity, URL.
Will reassign to joki since he had accepted that bug.
Severity: minor → normal
Component: Browser-General → Event Handling
Keywords: 4xp
QA Contact: elig → lorca
Resolution: WORKSFORME → ---
-> joki
Assignee: saari → joki


18 years ago
The bug occurs on my laptop, but not on a PC, though they are both running the
same OS (SuSE 6.2) in the same netwerk, as the same user, with the same WM. The
only significant difference I can think of is that on the laptop, the graphics
card does not use the accelerated mode, and is therefore many times slower.
On the PC, I can scroll down about 140 lines within 5 seconds, but on my laptop
it's only about 16 (!) lines.

Comparison between cursor-down (key) and the scrollbar's down-arrow (mouse):

                       | NN 4.x         | Mozilla
cursor down key:       |                |
- pressed frequently   | not queued up  | queued up
- holding down         | not queued up  | queued up
scrollbar down-arrow:  |                |
- pressed frequently   | queued up      | queued up
- holding down         | not queued up  | not queued up

This bug is about the difference in the behaviour between Moz and 4.x in both of
the cursor-down key cases.

Possibly relevant lines from my XF86Config (for XFree86 3.3.2):

from Section "Keyboard":
   AutoRepeat      500 5

from Section "Monitor":
   Identifier        "SHARP Mebius MN-6350D"

from Section "Device":
   BoardName         "Trident Cyber 9385 (generic)"
   VideoRam          4096

Section "Screen":
   Driver            "SVGA"

I'm downgrading the severity again because the majority of users is not affected.
Severity: normal → minor
The differences probably also have to do with performance.  If it takes longer
to repaint the exposed section of the page than the time between key repeats,
then key-presses queue up.  This varies by page and by system.

What would be nice to do, if it were possible to implement, is to scroll down by
a distance proportional to the number of key-presses in the queue, and remove
all those presses from the queue (or note that the next n down-arrow key presses
(or whichever key it is) have to be ignored).  This would give constant
performance although we would skip lines/pages sometimes.

Comment 22

18 years ago
Changing Status for my reference.  Was NSBETA3-.  Anyone think this 
should be renominated?
Whiteboard: [nsbeta3-] → [nsbetadenied]
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

Comment 24

18 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 25

17 years ago
*** Bug 125744 has been marked as a duplicate of this bug. ***


17 years ago
OS: Linux → All
Hardware: PC → All


17 years ago
Keywords: topembed

Comment 26

17 years ago
giving to myself, moz 1.01, topembed- as per EDT
Assignee: joki → saari
Keywords: topembed → topembed-
Target Milestone: Future → mozilla1.0.1


17 years ago
QA Contact: madhur → rakeshmishra

Comment 27

17 years ago
David, you don't have to invent a solution. Take a look at Andreas table.
Can't we just make the <cursor down key> hold trigger the same function 
as the <scrollbar down-arrow> (same for up)? This should at least solve 
the "holding down" problem.

There might be more people with slow hardware (think about embeeded devices).
This bug is not about making a slow scrolling faster, but to make a slow
scrolling behaving correctly.

Comment 28

16 years ago
->bryner, but not high priority
Assignee: saari → bryner
Whiteboard: [nsbetadenied] → [nsbetadenied], T2


16 years ago
QA Contact: rakeshmishra → trix

Comment 29

16 years ago
I'm not very familiar with the mozilla source, but this bug is currently the
only thing about the mozilla browser that really bothers me, so I wanted to
chime in with a few comments.

I don't think this issue really has anything to do with the performance of the
machine, or the speed of repainting the window, consider the following...
  1) I've witnessed this behavior on some "high end" boxes, but not on other
     "lower end" systems.
  2) I've never seen this bug happen in Netscape 4.77 on the same machines
  3) I've never seen this problem when a user "mouse clicks and holds" the
     down/up scroll arrow buttons.  only when the user "presses and holds" 
     the down/up arrow keys.

I'm speculating here based purely on the behavior I'm witnessing, but It seems
to me that when mozilla detectss a "ButtonPress" even in the scroll arrow, it
moves the window pane down a line at a time untill the "ButtonRelease" even is
detected (or the Pointer leaves the button area).  But whenever a "KeyPress"
even is detected for the "Down" key, it scrolls one line -- letting lots of
KeyPress events that happen in quick succession to queue up while it's scrolling.

I would guess that what needs to be done, is for the event queue to be purged of
all Down/Up KeyPress events after the completion of each "scroll 1 line" action.

Comment 30

16 years ago
My comments: 

- this bug is quite severe on linux but not on windows on the same machine;

- it does not seem to depend on the hardware (plenty of ram and a fast cpu,
everything else is fast)

- it does depend on the size of the document being displayed - some longish W3C
standards are almost keyboard-unnavigable because of this bug

- Phoenix is no better in this department

It's a really annoying one, as scrolling is what one does a lot in a browser. An
ergonomic disaster.

Comment 31

15 years ago
Target Milestone: mozilla1.0.1 → Future

Comment 32

15 years ago
I have had this problem with FireFox since I started using it, on multiple
computers, some faster than others.  In my experience, it has a lot to do with
what is actually on the page.  If there is a tall flash app, for example,
scrolling slows down considerably.  Sometimes, when I press the middle button,
the move to the top (for scroll up) it moves intolerably slow (like 2 lines
every 3 seconds).

All the comments here are verified.  Penny arcade is a good example of how
images/flash can slow down scrolling in any fashion.  Check out this particular
PA post for testing.

Comment 33

15 years ago
Regarding last comment from "Greg Chila"...

> In my experience, it has a lot to do with what is actually on the page.  
> If there is a tall flash app, for example, scrolling slows down considerably.
> Sometimes, when I press the middle button, the move to the top (for scroll up)
> it moves intolerably slow (like 2 lines every 3 seconds).

That sounds like a seperate issue ... particularly since you mention "middle
button" (by which i assuming you mean the mouse)

What this bug is specificly addressing is that the behavior of pressing and
holding down an *arrowkey* does not have the same behavior as clicking and
holding down the mouse of a scroll arrow. -- it doesn't matter how "heavy" the
page is, it still happens.

for example, if i hold down the arrow key while looking at this page, and then
let go, I can see the problem: the page keeps scrolling after i let go of the
down arrow. 

(Of course, i'm still using "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3)
Gecko/20030318 Debian/1.3-1.01" so i'm a bad person to ask)
Removing the viewManager->ForceUpdate() calls in PresShell::ScrollLine and
PresShell::ScrollHorizontal fixes this, but I imagine it may cause lack of
painting on Windows.  If that's the case, I think the solution is to post a
normal-priority paint event to the end of the event queue only if there is none
posted already (so that if there are multiple keypresses in the queue they'll
all be processed first before the paint).  I need to test this on Windows...
Well, for Windows, the first testcase on bug 212366 is better...

Comment 37

13 years ago
(In reply to comment #35)
> Bug 203439 has a good testcase.
(In reply to comment #36)
> Well, for Windows, the first testcase on bug 212366 is better...

is the problem gone now that the above two bugs are fixed?

Comment 38

13 years ago
I have not seen it for some time.

Comment 39

13 years ago
(In reply to comment #38)
> I have not seen it for some time.

Do you have a link that still preforms poorly?

Are dbaron's links in comment 35 and 36 still slow?

Comment 40

13 years ago
wow, that is slow (  The summary line exactly matches my experience with that page.  I'm using on Debian/unstable with smooth scrolling disabled.
Assignee: bryner → events
QA Contact: trix → ian
Target Milestone: Future → ---

Comment 42

10 years ago
Jeff, do you agree this is now WFM?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2008092417 Firefox/3.0.3
Whiteboard: [nsbetadenied], T2 → [nsbetadenied], T2 closeme 2008-11-21
FWIW, bug 301029 (scheduled for Firefox 3.2) should fix the "queue up"
part of the problem on Linux when using key repeat.

Please file new bugs if there are still examples of slow scrolling
in Firefox 3.0 or later.  Thanks.

Last Resolved: 18 years ago10 years ago
Resolution: --- → WORKSFORME
Whiteboard: [nsbetadenied], T2 closeme 2008-11-21 → [nsbetadenied], T2
You need to log in before you can comment on or make changes to this bug.