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

Status: RESOLVED WORKSFORME

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

Description

[Ian Clarke]

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

[Sean Richardson]

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.

Comment 2

[Eli Goldberg]

I *think* this goes to Nisheeth. Thanks, Sean!

Comment 3

[Nisheeth Ranjan]

Don, you hold general browser bugs like this, right?  Please re-assign this to 
the right person if you don't.  Thanks.

Comment 4

[Eli Goldberg]

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

Comment 5

[don]

Chris, find out who really owns this ... maybe you? :-)

Comment 6

[chris hofmann]

can we get it before beta1?

Comment 7

[Phil Peterson]

PDT-

Comment 8

[don]

Move to M16 for now ...

Comment 9

[don]

Move to M20 target milestone.

Comment 10

[Sean Richardson]

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.

Comment 11

[Claudius Gayle]

over to saari for a look.

Comment 12

[saari (gone)]

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

[Peter Trudelle]

seems much better now, nsbeta3-

Comment 14

[Chris Waterson]

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

Comment 15

[saari (gone)]

This works for me

Comment 16

[Keyser Sose]

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

Marking as Verified.

Comment 17

[Loco]

*** Bug 52391 has been marked as a duplicate of this bug. ***

Comment 18

[Andreas Franke (gone)]

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.

Comment 19

[Andreas Franke (gone)]

-> joki

Comment 20

[Andreas Franke (gone)]

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.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Loco]

Changing Status for my reference.  Was NSBETA3-.  Anyone think this 
should be renominated?

Comment 23

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 24

[Madhur Bhatia]

QA contact updated

Comment 25

[Kathleen :Brade]

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

Comment 26

[saari (gone)]

giving to myself, moz 1.01, topembed- as per EDT

Comment 27

[Raphael Wegmann]

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

[saari (gone)]

->bryner, but not high priority

Comment 29

[Hoss]

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

[dmitry]

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

[Vedran Miletic]

retargeting

Comment 32

[Greg Chila]

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.

http://penny-arcade.com/news.php3?date=2004-06-23

Comment 33

[Hoss]

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)

Comment 34

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Bug 203439 has a good testcase.

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Well, for Windows, the first testcase on bug 212366 is better...

Comment 37

[Wayne Mery (:wsmwk)]

(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

[Jeff]

I have not seen it for some time.

Comment 39

[Wayne Mery (:wsmwk)]

(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?
  http://gamma.nic.fi/~tapio18/Opetus/index2.php3
  https://bugzilla.mozilla.org/attachment.cgi?id=127505

Comment 40

[Jeff]

wow, that is slow (http://gamma.nic.fi/~tapio18/Opetus/index2.php3).  The summary line exactly matches my experience with that page.  I'm using 1.5.0.1 on Debian/unstable with smooth scrolling disabled.

Comment 41

[Jeff]

https://bugzilla.mozilla.org/attachment.cgi?id=127505 is not slow.

Comment 42

[Wayne Mery (:wsmwk)]

Jeff, do you agree this is now WFM?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

Comment 43

[Mats Palmgren (inactive)]

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.
http://www.mozilla.com/firefox

-> WORKSFORME