Open Bug 593466 Opened 14 years ago Updated 2 years ago

Scrolling using the scrollbar's arrow buttons scroll only a few pixels at a time

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: u88484, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [softblocker][viewmanagerlink]) 

Scrolling using the scrollbar arrows buttons only scrolls 5 pixels at a time, no matter what page.  Scrolling using the trackpad, page up/down keys, and the scrollbar slider have no problem what so ever...only the arrow buttons.  This bug does not exists if smooth scrolling is disabled.

Regression range is between the 08-27-2010 and 08-28-2010 nightly builds.
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124

Bug 130078 looks like a good possible candidate for causing this.
Blocks: 130078
blocking2.0: --- → ?
I can't reproduce this. I tried existing profiles and new profiles, nightlies before 130078 and nightlies after 130078, x86 and x86-64, Windows 2000 and Windows 7 and Linux, smooth scroll on and smooth scroll off, clicking the arrow buttons on the scroll bar and pressing the arrow keys on the keyboard, and starting firefox with smoothscroll on and starting firefox with smoothscroll off (in case some setting didn't take effect after just toggling smooth scrolling without restarting it).

What do I need to do to reproduce this?
(In reply to comment #1)
> 
> What do I need to do to reproduce this?

Sounds like you covered pretty much everything.

All I did to confirm this is an actual firefox bug is use a new profile with the 8-27 and a new one for the 8-28 builds, as soon as I start firefox I enabled smooth scrolling.  No slow scrolling in 8-27 build and slow scrolling in 8-28 build.
Wait, so this bug is about slow scrolling? Or the actual amount that the page is scrolled?
(In reply to comment #3)
> Wait, so this bug is about slow scrolling? Or the actual amount that the page
> is scrolled?

Well both.  The page scrolls a few pixels, briefly stops, then resumes...over and over again.  The whole process got a lot slower and jagged.
Ok, so you're talking about clicking and holding on the scrollbar down arrow and/or repeatedly clicking on it?
Each click on the scrollbutton only scrolls 5 pixels, so this is about the *actual amount* that the page is scrolled.

Keeping the scroll down button pressed results in a sort of quickfiring of clicks, each doing a 5 pixel scroll, which results in slow 'scrolling' effect.
(In reply to comment #6)
> Each click on the scrollbutton only scrolls 5 pixels, so this is about the
> *actual amount* that the page is scrolled.

This bug is only about a regression in behaviour that happened recently. If this didn't change recently then you should file a new bug on this issue. With that said, did you see a change in the actual number of pixels scrolled when you click once on a scrollbar up/down arrow?
Can you try a 2010-09-12 nightly or newer to see if anything has changed?
Any change in a current nightly?
Nope, no change.  Sorry I missed your question last time.
Scrollbar button clicks should go through nsGfxScrollFrameInner::ScrollBy so that's a good place to start looking.
Assignee: nobody → chris.double
I can't reproduce this on x86-32 Windows 7. Each click on the scrollbar arrow on the page scrolls down in exactly the same manner as if I press the arrow keys on the keyboard. Is it a win64 only issue? I tried the 2010-08-27 and 2010-08-28 nightly builds.
It seems the issue happens when you click and hold on the down arrow, either with jerkiness or scrolling the entire page takes longer.
I guess we can't reproduce this.
I don't see it clicking and holding the arrow either. Does it happen on all pages or a specific page? I tried with the WHATWG spec page.
Smooth scrolling should be on. Maybe try disabling hardware acceleration?
Smooth scrolling is on. My laptop doesn't do hardware acceleration. Scrolling is slower when holding the scroll arrow down vs using the keyboard but not that bad. How noticeable is the effect you are seeing? Any chance of a screencast?
(In reply to comment #15)
> I don't see it clicking and holding the arrow either. Does it happen on all
> pages or a specific page? I tried with the WHATWG spec page.

Pretty much every single page that you can can scroll vertically.  I can reproduce it on this bug page.

(In reply to comment #17)
> Smooth scrolling is on. My laptop doesn't do hardware acceleration. Scrolling
> is slower when holding the scroll arrow down vs using the keyboard but not that
> bad. How noticeable is the effect you are seeing? Any chance of a screencast?

Very noticeable.  I can do a screencast if someone can suggest a free program to use to make one.
http://dl.dropbox.com/u/12307421/slow%20scrolling.mp4

First portion is scrolling while holding the down and then the up arrow.  The second portion is holding the mouse down on the scrollbar's down and then the up button.
Thanks for that. I see pretty much what you show in the screen shot, only scrolling with the scroll arrow is a little bit faster. Are you expecting that holding down the scroll arrow should be as fast as holding down the arrow keys?
I think most people would..
Hmm. Then the code that handles mouse-down on the scrollbar arrows would somehow need to look up your keyboard repeat rate. We've never done that before. Is that really a blocker bug?
I thought this bug was about a regression on trunk?
I guess so, but it's unclear to me from the bug comments what specifically regressed.

Kurt, can you answer comment #7?

Did the amount we scroll at each step while you're pressing the scrollbar button change? Or did the frequency at which we perform those scroll steps change?
(In reply to comment #21)
> Thanks for that. I see pretty much what you show in the screen shot, only
> scrolling with the scroll arrow is a little bit faster. Are you expecting that
> holding down the scroll arrow should be as fast as holding down the arrow keys?

It is a lot slower!  It would take about a minute to scroll this bug while using the down arrows would take about 10 seconds.

> Are you expecting that
> holding down the scroll arrow should be as fast as holding down the arrow keys?
It should be the same speed, not turtle versus rabbit mode.

(In reply to comment #23)
> Hmm. Then the code that handles mouse-down on the scrollbar arrows would
> somehow need to look up your keyboard repeat rate. We've never done that
> before. Is that really a blocker bug?

(In reply to comment #24)
> I thought this bug was about a regression on trunk?

It is a regression.  The regression range is in comment 0.

(In reply to comment #25)
> I guess so, but it's unclear to me from the bug comments what specifically
> regressed.
> 
> Kurt, can you answer comment #7?
> 
> Did the amount we scroll at each step while you're pressing the scrollbar
> button change? Or did the frequency at which we perform those scroll steps
> change?

The frequency.
I'm still unable to see a regression on Windows 7 x86-32. Nightly builds prior to 2010-08-26 scroll at the same speed for me as current trunk. Is anyone else on x86-64 able to see the regression?
Scrolling is even slow with very basic HTML code so I don't think it is anything specific on the page that causes the issue, just makes it more noticeable.

Basic HTML code was (with a couple hundred numbers):

<html>
<head></head>
<body>
<br>1
</body>
</html>

Hardware info:
HP Pavilion dc9700
NVIDIA GeForce 7150M / nForce 630M Drivers: 7.15.11.7948
Direct2D Enabled false
DirectWrite Enabled false
GPU Accelerated Windows 1/1 Direct3D 9
Actually this happens when you turn on smooth scrolling with 3.6.12 also.   I also noticed that D3D9 for me is actually choppier smooth scrolling then D3D10.  But the other thing is, if I use a microsoft app like excel, we have parity there already when holding down the scroll buttons with the mouse.
Whiteboard: [softblocker] → [softblocker][viewmanagerlink]
Could anyone who saw this re-test in a 2011-02-10 nightly or newer and see if anything has changed?
(In reply to comment #30)
> Could anyone who saw this re-test in a 2011-02-10 nightly or newer and see if
> anything has changed?

No change on 2011-02-12 build
(In reply to comment #32)
> Anybody want to try this try build
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/cpearce@mozilla.com-09f7f419b279/
> and see if anything is changed?

"The requested URL /pub/mozilla.org/firefox/tryserver-builds/cpearce@mozilla.com-09f7f419b279/ was not found on this server."
I didn't notice any improvement with the try build.
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
This issue is most likely fixed by the change for Bug 710373.
(In reply to Manoj from comment #37)
> This issue is most likely fixed by the change for Bug 710373.

This bug was about a regression, but the actual number of pixels scrolled was not what was regressed, so I don't think that is related.
Assignee: chris.double → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.