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.
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.
QA Contact: nobody → elig
I *think* this goes to Nisheeth. Thanks, Sean!
Assignee: nobody → nisheeth
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
Doh. So this isn't due to Gecko infrequently doing frame updates, then?
Chris, find out who really owns this ... maybe you? :-)
Assignee: don → mcafee
Target Milestone: M15
can we get it before beta1?
Move to M16 for now ...
Target Milestone: M15 → M16
Move to M20 target milestone.
Target Milestone: M18 → M20
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
over to saari for a look.
Assignee: mcafee → saari
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.
seems much better now, nsbeta3-
Target Milestone: M20 → Future
*** Bug 31606 has been marked as a duplicate of this bug. ***
This works for me
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Worksforme: Platform: PC OS: Red Hat 6.2 (Linux 2.2.14) Mozilla: 2000101212 M18 Trunk Build Marking as Verified.
Status: RESOLVED → VERIFIED
*** 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
Status: VERIFIED → REOPENED
Component: Browser-General → Event Handling
QA Contact: elig → lorca
Resolution: WORKSFORME → ---
Assignee: saari → joki
Status: REOPENED → NEW
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.
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
QA contact updated
QA Contact: gerardok → madhur
*** Bug 125744 has been marked as a duplicate of this bug. ***
giving to myself, moz 1.01, topembed- as per EDT
Assignee: joki → saari
Status: ASSIGNED → NEW
Keywords: topembed → topembed-
Target Milestone: Future → mozilla1.0.1
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.
->bryner, but not high priority
Assignee: saari → bryner
Whiteboard: [nsbetadenied] → [nsbetadenied], T2
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.
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.
Target Milestone: mozilla1.0.1 → Future
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
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...
Bug 203439 has a good testcase.
Well, for Windows, the first testcase on bug 212366 is better...
(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?
I have not seen it for some time.
(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
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 184.108.40.206 on Debian/unstable with smooth scrolling disabled.
Assignee: bryner → events
QA Contact: trix → ian
Target Milestone: Future → ---
Jeff, do you agree this is now WFM? Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:220.127.116.11) 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. http://www.mozilla.com/firefox -> WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 10 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.