As far as i can see, this bug affects us.
I also found a relative reliable way to reproduce this bug.

Because this affects a page from our customer, i don't want to post the information in public.

As far as i can see, is the "scroll" not triggered anymore.
The "mousewheel" event is triggered though.

One of the steps to reproduce this bug is to scroll while a browser redirect is triggered via Javascript. So, this might be the cause of the problem.

If you need more information, contact me.

BTW:
My Chrome Version is 57.0.2987.110 (64-bit)
OS: Windows 10

 rakib.amin@ thank you for the bug, But without a URl or testcase we can't debug the issue further. Please note if the URL is confidential please provide us a normal reduced testcase(html) which exhibits the bug.

Happens to me as well on http://www.neogaf.com/forum/forumdisplay.php
It happens sometimes if I scroll while going from page to page via the "1" "2" links. 
Basically click the link and scroll all the time.
Started happening only a week or so ago.

Please read the chrome help forum thread about this issue
https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chrome/camZVtTiGyo/vxsz0mLnEAAJ

There are quite a few people including me that have this problem.

https://www.amazon.com/ask/questions/asin/B01CCMOMM0/11/ref=ask_ql_psf_ql_hza?isAnswered=true is an example of where the problem occurs.

To repoduce the the problem start going through the pages and then go back a page.  When you then go to the next page then the mouse wheel stops responding.

It ONLY affects the tab you are currently viewing and the mouse wheel continues to work in other tabs that are open.

btw,  Chrome Version 57.0.2987.110 (64-bit)
Windows 10

Thanks for the Steps to reproduce. If the tab is in focus the Arrow keys work during the situation. I checked the console, nothing there.

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I have bisected this manually using bisect-builds.py, which gives the following range:

"You are probably looking for a change made after 435502 (known good), but no later than 435517 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/90653cee40f4651debda27fc33f34bac224fd473..eb080bd2b9753c6956b69a48cdb67fc085bc9d5c"

This is on 64-bit Windows 10 Enterprise. To reproduce the bug, I went to reddit.com and clicked "comments" on various posts while spamming my scroll wheel. If it didn't trigger, I went back to the front page and tried again. The bad revisions would usually trigger in ~5-10 attempts. I also re-ran bisect-builds with --verify-range afterwards.

Happening for me with Chrome Version 57.0.2987.98 (64-bit) running on Ubuntu 16.04.2 LTS on a Lenovo Thinkpad X1 Yoga. Regularly occurs on http://www.smh.com.au/. Works for a while, then stops working. Closing then re-opening the tab restores working behaviour. 

I can reproduce the issue as well running 58.0.3029.33 beta (64-bit) on Windows 10 I can reproduce it on any site that requires scrolling.   I am using a Logitech MX Master and the Logitech Options app v 6.40.169.  All options are set to defaults.  This issue occured intermittently in the non-beta version, usually after a few minutes of being on any site that required scrolling.   I can still scroll with the up and down arrows, but the scroll wheel has no function. 

Any apps outside of Chrome work fine.    I have disabled all extensions, cleared my profile, completed a complete reinstall of chrome and still the issue persists.    


https://androidforums.com/

Today the issue occurred almost 1 in every three tabs. I am beginning to think this thread is being ignored. Unless of course, they need more data / people reporting this. Any idea how to raise the issue? 

As others have said, this is a chrome specific issue that can be recreated on just about any site, regardless of plugins/js running.

To recreate, load a page that has a scrollbar. Once the page is loaded, keep refreshing [F5] the page while scrolling. You should be able to lock up the scroll wheel from working, forcing you to either manually scroll, or to close tab.

This bug is very simple:

Steps:
1. Update to the latest version of Chrome browser (as of 3/29/17@1pm, that would be Version 57.0.2987.133, which I just updated to).
2. Visit ANY website, such as www.Apple.com.
3. Use scroll wheel to confirm it's working correctly.
4. Click any link to navigate to a new page, and IMMEDIATELY scroll continuously up and down (as if you're in a hurry). 

Apple's site, of course, loads VERY fast, so you need to be scrolling constantly pretty much, as you click the link, and until the new page loads. But I use Apple as an example to show that, even if your load speeds are top notch, this issue can still happen if you're browsing in a hurry.

Result: When the new page loads, scrolling using scroll wheel doesn't work (arrow keys do). 

Expected: Scrolling with scroll wheel works.

Notes:
- These steps reproduce the bug for me on ANY site I've tried so far.
- Navigating to a new page doesn't fix the bug.
- Refreshing doesn't fix the bug.
- New browser tabs are unaffected, so you could open a link (Ctrl/right-click) in a new tab (instead of within your current tab), to workaround the issue.

One additional piece of information.  

If you use the back and forward buttons on the mouse then the bug is triggered.  However, if you use the back and forward buttons on the browser itself then I don't see the issue.  

Also, when the bug is triggered I have found that I open a new tab and then use the back and forward buttons on my mouse until I trigger the bug that I can then go back until I'm back at the new tab page and then go into the site again and the bug will temporarily clear.

bokan@, can you take a look or reassign?

I managed to repro using the repro steps on comment #15 on canary on Windows.

I can repro on Linux ToT. I haven't debugged, but the behavior looks specific to scrolling during a navigation. I'm guessing the compositor is somehow getting confused about the page going away, since the MouseWheel events are still arriving and getting processed, but animation isn't happening.

Able to reproduce the issue on latest Chrome stable i.e., 57.0.2987.133 on Windows(Still have to check on Mac and Linux), Please find the bisect range below :

Bisect result :

You are probably looking for a change made after 435502 (known good), but no lat
er than 435503 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/90653cee40f4651debda27fc33f34bac224fd473..e7592f02242026970af0a6425928e5271a52f79d

In order to reproduce I have used the steps provided in Comment#15 and we have to perform the refresh and scroll simultaneously and quick.

This is working fine in M56, This is regression in M57 before the branch point.

cc'ing mikelawther@  and ajuma@

Hi Robert - both loyso@ and ajuma@ are OOO at the moment. I think you might have the most context about the composited animations area that this has been bisected down to. 

Can you help or suggest someone who can? Thanks!

(I'm just assigning this so it doesn't get lost - please [un|re]assign as needed)

I can confirm that the repro instructions in C#16 worked for me: not every navigation from apple.com showed the problem, but usually at most two or three tries are sufficient.

I can add a bit of info here, as I am currently investigating an unrelated scrolling bug, and have a build set up with some diagnostic outputs.

It seems that, when the problem occurs, the scroll tree in the compositor

ScrollTree& scroll_tree = active_tree_->property_trees()->scroll_tree;

doesn't update properly - in particular, it seems to be remembering the state (CurrentlyScrollingNode) for the previous page, i.e. before the navigation. The viewport()->MainScrollLayer() also appears to be stale.

When the problem doesn't occur, the ScrollTree values appear to change over the course of the navigation.

I'm going to suggest we bump this to Pri-1, in case this is a symptom of a bigger problem. Rob, feel free to grab me today if you want a demo.

I can repro this as well - that's pretty bad :/

Not sure it's specifically related to animations - I'll take a look.

Talking to rbyers@ I found out sahel@ has been working on wheel-latching ... sounds kinda related (especially if the latching doesn't disengage during the navigation for some reason ...), so adding them as well.

Spoke too soon, definitely related to animations. Disabling chrome://flags/#smooth-scrolling fixes the issue. The investigation continues...

Are you sure it fixes the issue, or does it perhaps just make the issue super-hard (impossible?) to repro? (Just playing devil's advocate here ...)

Perhaps it's possible that it just masks the issue due to timing but the bisect pointed to a change in animations so it makes sense.

 crbug.com/689661  is another example of the issue: scrolling freezes when smooth-scrolling is enabled. The cause might be the similar since some of the suspected cls are in common:
https://chromium.googlesource.com/chromium/src/+log/bf6d43497a90e2ab8532e3a4d48e3c4c88324550..ceea98f08d159ea989123a2908e949fc3fd49b04

 As mentioned by bokan@ in comment#31, I wasn't able to reproduce the issue by disabling chrome://flags/#smooth-scrolling.

chatting with pbommana@, I think we should block 57 shipping until this is resolved.

So 57 is basically too late to stop for this. Given that there's a work around in #31 and the issue doesn't hit everyone I'm removing RBS. I'll try to have a fix in ASAP

flackr@ or skobes@, are either of you more familiar with smooth scrolling and Impl->Main hand-off for animations? I'm trying to dig into this but I don't know the code that well, would be helpful to have someone more familiar take a look as this is rather urgent.

Per chat with jainabhishek@ (ConOps POC), so far we've total 53 reports from unique clients (Note: M57 has been out for small percentage of Windows and Mac, 100% of Linux users since 03/09).

+ ketakid@ (Chrome OS TPM)

I have a patch in http://crrev.com/2788773002 that reverts the changes in  issue 669755  (implicated by bisect in #20).  I verified locally that it fixes this issue, but I don't understand the exact mechanism.

Thanks Steve. I'm still prodding at the ToT code to try to figure out exactly where this is going wrong.

Minimized repro: https://output.jsbin.com/fakucaq/quiet

I may have found the issue. I have a fix up at https://codereview.chromium.org/2791513002/ but would like someone familiar with the CC animation system to take a look. Both ajuma@ and loyso@ are out, anyone know who else might know this code?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a064840eb26683687c53dc6fa6b5c29a2c418b5c

commit a064840eb26683687c53dc6fa6b5c29a2c418b5c
Author: bokan <bokan@chromium.org>
Date: Fri Mar 31 01:01:02 2017

Reset is_ticking_ when calling AnimationPlayer::RemoveFromTicking

it_ticking_ isn't cleared in this path. This means that future
animations wont be started since UpdateTickingState will think that its
already ticking and wont add itself to the AnimationHost's ticking
players list.

I believe the omission in
https://crrev.com/e7592f02242026970af0a6425928e5271a52f79d was that
when the scrolling Element is unregistered the ElementAnimations will
be removed from AnimationHost. In contrast, the AnimationPlayer lives on.
That's why ElementAnimations didn't need to clear the active/ticking
flag but AnimationHost does.

BUG= 704410 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2791513002
Cr-Commit-Position: refs/heads/master@{#460966}

[modify] https://crrev.com/a064840eb26683687c53dc6fa6b5c29a2c418b5c/cc/animation/animation_player.cc

The above patch should fix the issue. If all goes as planned this should be included in tomorrow's Canary build. From there, we'll let it bake for a bit and hope to merge it into stable next week.

Test is also TODO so I'll land that separately once ajuma@ or loyso@ can review the fix.

Verified the fix on Windows 7 with latest Chrome Canary i.e., 59.0.3062.0. 

ajuma@ took a look at the submitted fix and confirmed it looks correct. Requesting merge to both M57 and M58.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f6734c8dffedf23afafec4c901880122418b5aee

commit f6734c8dffedf23afafec4c901880122418b5aee
Author: David Bokan <bokan@chromium.org>
Date: Tue Apr 04 17:52:23 2017

Reset is_ticking_ when calling AnimationPlayer::RemoveFromTicking

it_ticking_ isn't cleared in this path. This means that future
animations wont be started since UpdateTickingState will think that its
already ticking and wont add itself to the AnimationHost's ticking
players list.

I believe the omission in
https://crrev.com/e7592f02242026970af0a6425928e5271a52f79d was that
when the scrolling Element is unregistered the ElementAnimations will
be removed from AnimationHost. In contrast, the AnimationPlayer lives on.
That's why ElementAnimations didn't need to clear the active/ticking
flag but AnimationHost does.

BUG= 704410 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2791513002
Cr-Commit-Position: refs/heads/master@{#460966}
(cherry picked from commit a064840eb26683687c53dc6fa6b5c29a2c418b5c)

Review-Url: https://codereview.chromium.org/2793383002 .
Cr-Commit-Position: refs/branch-heads/3029@{#572}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/f6734c8dffedf23afafec4c901880122418b5aee/cc/animation/animation_player.cc

Fix has been verified in M58 (58.0.3029.53) on Linux and Windows

Approving merge to M57 Chrome OS.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eb35233983ef11b699c65fea41091b32cfc4b4d9

commit eb35233983ef11b699c65fea41091b32cfc4b4d9
Author: David Bokan <bokan@chromium.org>
Date: Tue Apr 04 23:28:01 2017

Reset is_ticking_ when calling AnimationPlayer::RemoveFromTicking

it_ticking_ isn't cleared in this path. This means that future
animations wont be started since UpdateTickingState will think that its
already ticking and wont add itself to the AnimationHost's ticking
players list.

I believe the omission in
https://crrev.com/e7592f02242026970af0a6425928e5271a52f79d was that
when the scrolling Element is unregistered the ElementAnimations will
be removed from AnimationHost. In contrast, the AnimationPlayer lives on.
That's why ElementAnimations didn't need to clear the active/ticking
flag but AnimationHost does.

BUG= 704410 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2791513002
Cr-Commit-Position: refs/heads/master@{#460966}
(cherry picked from commit a064840eb26683687c53dc6fa6b5c29a2c418b5c)

Review-Url: https://codereview.chromium.org/2803503002 .
Cr-Commit-Position: refs/branch-heads/2987@{#907}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/eb35233983ef11b699c65fea41091b32cfc4b4d9/cc/animation/animation_player.cc

The fix has been merged to both M57 and M58 at this point.

I'm going to leave the bug open until I can land a test in ToT.

Great work bokan! Thanks for the super quick attention to this.

Verified the issue on windows 7 & ubuntu 14.04 using chrome M58 #58.0.3029.54 with the steps mentioned in comment #16.

Mouse wheel scroll works in the new links openened in same page , as attached in screencast for reference.

Adding Te-Verified Labels.

Thanks!

Deleted: 704410.mp4 10.5 MB

	704410.mp4 10.5 MB View Download

is this fixed ? please mark it as fixed, otherwise it won't show up in the verification list.

I still need to land a test, I'm hoping to have that in tomorrow. If this significantly impacts the bug process then feel free to move it to Fixed.

Verified this issue based on comment #16 on Chromebooks auron-paine & Falco with version 9202.64.0, 57.0.2987.146.  (tested on apple.com, google.com sites)

Verified on M57 build 9202.64.0/57.0.2987.146

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b9dcad92b7ad50e6025f3e326af8ccf1f3a07e5c

commit b9dcad92b7ad50e6025f3e326af8ccf1f3a07e5c
Author: bokan <bokan@chromium.org>
Date: Fri Apr 07 20:26:53 2017

Add test for removing and adding ticking AnimationPlayer

This is a test for the urgent fix landed in crrev.com/2791513002.

BUG= 704410 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2807753002
Cr-Commit-Position: refs/heads/master@{#462985}

[modify] https://crrev.com/b9dcad92b7ad50e6025f3e326af8ccf1f3a07e5c/cc/animation/element_animations_unittest.cc

And test landed, marking straight to verified as per #58, #61, and #62

When will Chrome be fixed to scroll properly?

This is my first post.  Sorry for any incorrect formatting.

I am having the same issue randomly. I haven't installed any extensions on chrome and I keep this computer clutter free. I only install what I need and I have virus scanner software (Bitdefender) on this machine.  I can scroll the page manually with the scroll bar, but not with the mouse wheel.

I love chrome and I hope it gets fixed soon. :)

Hi there. The fix missed version 57 on most (all?) platforms. But the good news is that it should ship in version 58, which according to https://www.chromium.org/developers/calendar should *about* next week. You can check what version you're in in chrome://version.

In the mean time, you can fix the issue by disabling chrome://flags/#smooth-scrolling

Confirmed this bug still exists in Chrome 57.0.2987.133 (64-bit)

This patch is now pushing out to stable channel in version 58.0.3029.81 for Desktop. Thank you.

I checked using the  cdhi...@'s step to reproduce (Amazon pagination), no issues.

Life is Good again. Thank you all. 

 Issue 712791  has been merged into this issue.

I was able to repo this issue, after some people were telling me about it.
I'm using version 57.0.2987.133 (Official Build) (64-bit) on Windows. and after disabling chrome://flags/#smooth-scrolling I was not able to repo this issue.

The fix is in M58. Please update Chrome. Goto Help>About Chrome.

Yeah yeah, just updated. all is fine, cant repo

 Issue 710462  has been merged into this issue.

I am also facing this problem.
Please fix the bug and make another update.

If you're still seeing something similar please file a new bug at https://crbug.com/new and we can investigate from there. Thanks.

I having this issue on this bug page with a Logitech mouse. My touchpad still scrolls fine. If I close Chrome and reopen, scrolling works for a while but then stops randomly

Please file a new bug https://crbug.com/new if you're seeing issues.

i am having this  problem, my screen scrolls by itself.......since i updated to last version

Re #81: The issue tracked by this bug has been solved. If you're seeing a similar issues, please file a new bug with all relevant details at https://crbug.com/new.

I'm having this problem with Version 61.0.3163.79 (Official Build) (64-bit). I want to use Chrome badly but cannot because of this **stupid** issue - the other issue is that on Windows, Chrome doesn't use ClearText, so the font is very hard to read, unlike Firefox. 

Re #83: The issue tracked by this bug has been solved. If you're seeing a similar issues, please file a new bug with all relevant details at https://crbug.com/new.