Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 23 users
Status: Verified
Closed: Jan 2013
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

Sign in to add a comment
Mouse wheel scrolls very slowly when set to page-up/down in Windows
Project Member Reported by, Nov 8 2012 Back to list
Version: 24.0.1312.5 (Official Build 166104) beta-m
OS: Windows 7 64-bit

What steps will reproduce the problem?
1. Update to the just-released Chrome 24 beta.
2. Set Windows mouse wheel settings to scroll "one screen at a time" (see attached screenshot)
3. Visit a website that needs vertical scrolling, such as Google search results, and try scrolling with mousewheel.

What is the expected output? What do you see instead?
I expect the site to scroll a page per wheel tick.  Instead, it scrolls a PIXEL per tick.

This only seems to happen if the scrollable region is the whole page.  Framed pages scroll correctly; Google News, which uses a custom scrollbar thingy, works correctly; The bug-report textbox I'm typing in, and the bug-labeling dropdowns, also scroll correctly.

I get the impression that Windows's "one screen at a time" thing works by setting the "number of lines" value to -1.  I've seen programs that mistakenly scroll backward on this setting, including an early version of Chrome IIRC.
26.8 KB View Download
Comment 1 by, Nov 9 2012
A large image opened in its own tab scrolls properly, jumping a screen per tick.

Interestingly, on this bug page, the scroll behavior is slow for the upper half, but becomes normal page-up/down a little past halfway down the page.
Comment 2 by, Nov 9 2012
>Interestingly, on this bug page, the scroll behavior is slow for the upper half, but becomes normal page-up/down a little past halfway down the page.

Looks like this only works after clicking in the comment box to activate it.  (You can click outside afterward and it'll still work.)  If you don't click in the comment box and leave it grayed out, the whole page scrolls slowly.
Comment 3 by, Nov 9 2012
Wait, scratch that, it works even if you don't click in the comment box.  (Might be interesting to see how behavior changes as the page lengthens with comments.)
Comment 4 by, Nov 10 2012
"Google News, which uses a custom scrollbar thingy, works correctly"

On second try, it only works right if the mouse is hovering over the custom scrollbar area.  If it's in the main area of the page, it scrolls slowly.
Comment 5 by, Nov 11 2012
Looks like hovering over the scrollbar on *any* page makes the wheel page-up/down properly.  That makes things more bearable in the meantime, but I hope this bug is fixed soon.
Comment 6 by, Nov 12 2012
Chromium 25.0.1324.0 (Developer Build 167131) seems to work correctly.  I'd test earlier builds, but all the folders here show up empty:

If that link's outdated, FYI, it came from here:
Comment 7 by, Nov 14 2012
Google News sometimes works correctly and sometimes doesn't.  Has something to do with where the mouse pointer hovers.  Weird.
Comment 8 by, Nov 15 2012
Labels: Area-WebKit
Still busted in the new beta, 24.0.1312.14 (Official Build 167497) beta-m.

Tentatively marking as Webkit, since fiddling with Google News produces different results.
Comment 9 by, Nov 16 2012
Labels: Action-BisectNeeded
Comment 10 by, Nov 18 2012
Regarding the continuous builds link, it turns out I just had to wait a bit for the directory to appear.  (There's no loading indication at first, hence my confusion.)

The bug appears in the two 24 betas that've been released so far:

24.0.1312.5 (Official Build ?) beta-m 11-08-12: fails
WebKit: ?

24.0.1312.14 (Official Build 167497) beta-m 11-14-12: fails
WebKit: 537.17 (@134459)

I've tested the continuous builds around the 24/25 transition, but strangely they all work correctly:

24.0.1311.0 (Developer Build 164600) 10-29-12: works
WebKit	537.17 (@132751)

24.0.1312.0 (Developer Build 164840) 10-30-12: works
WebKit	537.17 (@132834)

24.0.1312.0 (Developer Build 164865) 10-30-12: works
WebKit	537.17 (@132834)

24.0.1312.0 (Developer Build 164874) 10-30-12: works
WebKit	537.17 (@132834)

---- Version changes from 1312 to 1313 here ----

24.0.1313.0 (Developer Build 164883) 10-30-12: works
WebKit	537.17 (@132834)

24.0.1313.0 (Developer Build 164916) 10-30-12: works
WebKit	537.17 (@132872)

24.0.1313.0 (Developer Build 165011) 10-30-12: works
WebKit: 537.17 (@132885)

24.0.1313.0 (Developer Build 165044) 10-31-12: works
WebKit	537.17 (@132885)

---- version changes from 24 to 25 here ----

25.0.1313.0 (Developer Build 165071) 10-31-12: works
WebKit	537.17 (@132891)

25.0.1313.0 (Developer Build 165096) 10-31-12: works
WebKit	537.17 (@132891)

25.0.1314.0 (Developer Build 165198) 10-31-12: works
WebKit	537.17 (@133029)

25.0.1315.0 (Developer Build 165408) 11-01-12: works
WebKit: 537.18 (@133141)

25.0.1316.0 (Developer Build 165810) 11-03-12: works
WebKit	537.18 (@133306)

25.0.1325.0 (Developer Build 167484) 11-13-12: works

Does this narrow down the cause to a change made on the 24 beta branch?
Labels: -Action-BisectNeeded
Able to repro the issue and below is the bisect Info:

25.0.1325.0 - Good
25.0.1326.0 - Bad

You are probably looking for a change made after 167683 (known good), but no lat
er than 167744 (first known bad).
CHANGELOG URL: nk/src&range=167683%3A167744

@ mkterra - Bisect provided in comment 10 doesn't match with the Bisect info provided here. Can you please recheck the same ?
Comment 13 by, Nov 21 2012
Labels: -Pri-2 Pri-1 Mstone-25
Comment 14 by, Nov 28 2012
@smokana: Thanks!  The bisect info doesn't contradict; I only tested up to 1325 before.  Now I can confirm the below:

25.0.1326.0 (Developer Build 167683): works
WebKit	537.19 (@134347)

25.0.1326.0 (Developer Build 167744): fails
WebKit	537.19 (@134601)
I have this issue as well on Chromium Version 25.0.1323.1 (167142).
Comment 16 by, Jan 12 2013
I'm suddenly having the same problem. Only some websites, but still a high percentage (over half).
Comment 17 by Deleted ...@, Jan 12 2013
Yes...  on certain web pages if you hover your mouse over the scroll bar, it scrolls one "page" at a time.  However, if you're on the actual web page (graphics, text, etc.) it only scrolls one pixel at a time.  I can replicate on 24.0.1312.52 (x64), Windows 8, mouse set to "one page a a time."
Comment 18 by, Jan 13 2013
@16: Probably because Chrome 24 just hit Stable channel.

I use this constantly, so I've retreated to Firefox while this is broken.
Comment 19 by, Jan 13 2013
 Issue 169529  has been merged into this issue.
Comment 20 by, Jan 13 2013
Confirming reproduction on 24.0.1312.52 m on Windows 7 Ultimate 64-bit.

Nice late Christmas gift.  Thanks.
Comment 21 by Deleted ...@, Jan 14 2013
Comment 22 by, Jan 14 2013
Status: Assigned
i think possible culprits are:

or maybe:

sami, can you take a look and see if your CLs are causing the problem.

Labels: -Mstone-25 Mstone-24 ReleaseBlock-Stable
Labels: Feature-GPU-Compositing
Mouse wheel events are now sent straight to the compositor thread and handled there as flings(?). We most likely don't respect the Windows setting on how much a single click in the scroll wheel should scroll by. 

James, is there any value in sending scroll wheels to the impl thread or should we go back to handling them on the main thread?  This would also address  issue 169283  . 

Dharani, is this really a pri-1 RLS ? 
Labels: -ReleaseBlock-Stable
Comment 26 by, Jan 14 2013
Out of curiosity, I timed how long it took me to get from the top of this page to the bottom, using only the scroll wheel.

First I removed the left sidebar using Printliminator.  This eliminates the dual behavior: "Interestingly, on this bug page, the scroll behavior is slow for the upper half, but becomes normal page-up/down a little past halfway down the page," making the entire page scroll incorrectly.

Working the scroll wheel pretty aggressively, it took 3 minutes and 32 seconds.
Labels: ReleaseBlock-Stable
We are getting internal reports also. Adding ReleaseBlocker-Stable label.
Re comment #24 - handling wheel events is most of the point of threaded compositing, so that wouldn't be ideal.  There must be some logic somewhere that examines this setting and figures out how far a wheel event should scroll the page - where is it?  I'd guess we will have to duplicate that.  Since it's already passed into the renderer process somewhere this can't be that hard.
Comment 30 by Deleted ...@, Jan 15 2013
More info that might be helpful...  use *this* actual web page with our discussion as an example.  I'm using Windows 8 x64 and latest Chrome build 24.0.1312.52.  Mouse wheel is set to "one page" at a time in Windows Control Panel.  When you start scrolling down, it scrolls one pixel at a time.  However, if you manually take your mouse and click/drag the window scroll bar (the "dark" part of the scroll bar) down to, say, the bottom of this page, the wheel "up" indeed scrolls one page at a time.  But once you get back to the top of the web page, the scrolling resumes to one pixel at a time.  You can also hit your "HOME" keyboard button to get to the top of the page (and thus trigger one-pixel mouse wheel scrolling) or hit your "END" keyboard button to get to the bottom of the page (and thus trigger one "page" mouse wheel scrolling).  Weird.  Can others confirm this?  It definitely happens in my setup...  back to Firefox for now I guess.  :(
This looks like the relevant bit:

I'll point out that I may not be the best owner for this bug since I don't currently have a Windows dev machine set up. I can try to scrounge one up though.
Thanks for the pointer, Sami. Brian, do you have some cycles to take this on (since you're already setup on windows)?
Comment 33 by Deleted ...@, Jan 15 2013
Same problem, started yesterday. Windows 8 64 bit, Chrome Version 24.0.1312.52 m 
Scrolling down one pixel at a time until it 'catches' and finally works correctly (one page at a time). From the bottom of the page it scrolls up one page at a time as it should.
Brian's plate is full. Taking this back!
Comment 35 by Deleted ...@, Jan 16 2013
Same problem, started yesterday, Windows 7 32 bit. Conflicting Windows update?
I have a chromium patch up here:

However, after implementing it I realized that the unintended side-effect of this change is that if a user starts scrolling while the page is still loading, they'll get lots of checkerboarding. I don't know that we'll want to unleash that behavior straight to the stable channel. 

I'm starting to think that we should send the scroll-wheel events back to the main thread, at least for M24 or until impl-side painting is completed.

For posterity, I'm attaching the webkit-side of this patch which I haven't yet uploaded to . 

12.2 KB View Download
Comment 37 by, Jan 16 2013
Go to About:flags Threaded compositing Mac, Windows, Linux, Chrome OS and set it to disabled. It will work fine afterwards.
@vangelis - here's that patch if we need it:
Comment 39 by Deleted ...@, Jan 16 2013
I had this same issue, but naelphin's post (#37) fixed it. Thanks!
Comment 40 by, Jan 16 2013
Echoed: naelphin's post #37 addressed it for me.
Ditto on post #37 containing the fix for me.
Comment 42 by, Jan 16 2013
Thanks to post #37 for fixing this annoyance ( Win 7 Pro 64 bit )
James, let's go with your fix for the time being.
@vangelis ok - wanna lgtm my patch then? :)
Project Member Comment 46 by, Jan 17 2013
The following revision refers to this bug:

r177369 | | 2013-01-17T09:16:49.863855Z

Changed paths:

Disable compositor thread input handling on windows

BUG= 160122 

Review URL:
Labels: Merge-Approved
Merging to 24/25 now
Project Member Comment 49 by, Jan 17 2013
Labels: -Merge-Approved merge-merged-1312
The following revision refers to this bug:

r177442 | | 2013-01-17T18:39:46.785828Z

Changed paths:

Merge 177369
> Disable compositor thread input handling on windows
> BUG= 160122 
> Review URL:

BUG= 160122
Review URL:
m24: r177442
m25: r177443
Status: Fixed
Closing this bug as fixed, we can treat handling these wheel settings on the compositor thread as a separate bug.
Project Member Comment 52 by, Jan 17 2013
Labels: merge-merged-1364
The following revision refers to this bug:

r177443 | | 2013-01-17T18:41:18.652641Z

Changed paths:

Merge 177369
> Disable compositor thread input handling on windows
> BUG= 160122 
> Review URL:

BUG= 160122
Review URL:
Labels: TE-Verified-24.0.1312.56
Status: Verified
Verified on 24.0.1312.56 and issue is fixed.
We really need to fix the actual bug.  Filed  bug 180655 
Project Member Comment 55 by, Mar 9 2013
Labels: -Type-Regression -Area-UI -Feature-Browser -Area-WebKit -Mstone-24 -Feature-GPU-Compositing Type-Bug-Regression Cr-Content Cr-Internals-GPU-Compositing M-24 Cr-UI Cr-UI-Browser-Core
Project Member Comment 56 by, Apr 5 2013
Labels: -Cr-Internals-GPU-Compositing Cr-Internals-Compositing
Project Member Comment 57 by, Apr 5 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment