Hi yamaguchi, could you please record a chrome://tracing report include: input, latencyInfo, events, views. Thank you.

It's most useful to check all the "Record Categories" boxes.

I've attached my tracing log.
During the recording, it scrolled normally in the first half of it, but it stopped after a few seconds.

Google Chrome	65.0.3325.18 (Official Build) dev (64-bit)
Revision	8537a0b30e659eefb087ec25b97a1a7f61e2d672-refs/branch-heads/3325@{#78}
OS	Linux

Deleted: trace_WheelScroll.json.gz 3.0 MB

trace_WheelScroll.json.gz 3.0 MB Download

Thanks for the trace yamaguchi@. I still can't reproduce this myself on Linux @ 65.0.3325.18.

In the trace I can see that up to ~5.7 seconds it seems we're scrolling ok, evidenced by occurrences of ScrollableArea::ScrollOffsetChanged on the Renderer's main thread (i.e. the changed offset is being committed from the compositor to the main thread).

After that, there's a ~2.3 gap where we're getting GSUs from the browser, the renderer is receiving them in InputHandlerManager::HandleInputEvent but nothing is happening. We start scrolling again after a KeyDown at around 8.3s.

Right before the gap we have several occurrences of:

"LayerImpl::tryScroll: Ignored not scrollable"
"LayerImpl::tryScroll: Ignored. Technically scrollable, but has no affordance in either direction."

I'm assuming this is step 2 from your comment #9 (keep scrolling after you hit the extent). I wonder if that's throwing something off.

Assigning to Sahel since she's the expert here. Unfortunately, it looks like after HandleInputEvent, the trace is a bit of a black hole. It seems we don't have great trace instrumentation for animated scrolls. Please add tracing events wherever would be helpful to diagnose why we stop processing the GSUs.

Also, yamaguchi@, I'm suspecting this might be related to the recently turned on scroll latching feature in M65. Could you please turn off the feature in chrome://flags/#enable-wheel-scroll-latching and see if you can still repro? And Sahel, please confirm that flag is sufficient to turn the feature off.

>1. Scroll down to the bottom of the document.
>2. Scroll down further about 20 times (multiple lines each time) by repeatedly turning the wheel.
>3. Try to scroll up by the wheel.

I tried to reproduce the bug on my Linux desktop and haven't been able to do that even with trying the second step several times.

yamaguchi@ please confirm whether you see the problem with latching disabled (you can disable it from chrome://flags) or not. Is it easier to reproduce it on chromeOS? 

Generally when we are hittesting on GSB we find the first element that can scroll in any of the given directions, and use this target for the rest of GSU events in the scroll sequence. If no scroller can consume any delta hints then the GSB gets ignored and the GSU events will get ignored for the rest of the scroll sequence till we receive a GSE.

Now if no scroller can consume the delta hints of a GSB (all of the scrollers are in their extents) we ALWAYS use the viewport as the target regardless of the scroll direction so that GSB doesn't get ignored. In this case if a later GSU comes with a different direction it will scroll the viewport.

Based on this explanation being at the extent of the page shouldn't cause the GSU with the opposite scroll direction get ignored when you try to scroll up unless if the GSB gets ignored for some other reason.

It reproduced on ChromeOS as well with the same steps.
I didn't see it when #enable-wheel-scroll-latching is disabled.

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

commit b567f9346cf2f7421233d2923ee7c639a3920605
Author: Sahel Sharify <sahel@chromium.org>
Date: Mon Feb 05 18:21:44 2018

Trace delta of GSUs in InputHandlerProxy::HandleGestureScrollUpdate.

This cl records the deltas of GSU events arrived to the renderer.
The trace helps with debugging cases that scroll events are unexpectedly
ignored.

Bug: 797708
Change-Id: I855caa42a0751e63df540f95e4345720f16befb1
Reviewed-on: https://chromium-review.googlesource.com/894179
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534426}
[modify] https://crrev.com/b567f9346cf2f7421233d2923ee7c639a3920605/ui/events/blink/input_handler_proxy.cc

I've added trace data for delta x and delta y to see if the scroll up event gets coalesced to the down events to the queue or not (see comment #23)

yamaguchi@, could you please record a new trace on ToT with input recording enabled? This will give more information about the cause of the issue.

Tested this issue on Ubuntu 14.04 on the reported version 65.0.3302.0 and unable to reproduce the issue by following the steps in the original comment.

On scrolling through the pages which has vertical scrollbar using mouse wheel, can scroll smoothly through the pages and cannot observe any issues.

sahel@ Can you please check and help us in verifying the fix on 66.0.3341.0.

Thanks..

The reproduction is not is easy (I haven't been able to reproduce it yet).
But it doesn't mean that the bug is fixed. That's why I've asked  yamaguchi@ to record the input trace.

My guess is that since AsyncWheelEvents is enabled, GSU events are Vsync aligned and they get coalesced while waiting for the Vsync signal and that's why scrolling upward gets ignored when it arrives after a lot of events scrolling downwards.

I am very sorry but I am getting other priority tasks. I will make sure to send report by EoW. Thanks!

Sorry for being late. Here is a trace (with all).

Google Chrome	66.0.3343.3 (Official Build) dev (64-bit)
Revision	e1f2ec046b66d1e2cd4ce82fecff22dad160fd54-refs/branch-heads/3343@{#4}
OS	Linux

Deleted: trace_WheelScroll_with_xy.json.gz 3.7 MB

trace_WheelScroll_with_xy.json.gz 3.7 MB Download

Thanks for the trace. It would help if you tell at which interval of the trace to look for the regressed behavior since the trace is 17 seconds and it has a lot of scroll events.

I've recorded it again.
I've put a key event this time by hitting 'n' key after noticing the regressed behavior.

- scroll successfully
- it stopped scrolling
- hit 'n' key
- attempted scroll, failed
- hit 'ctrl+r' to reload page
- scrolled successfully again

I guess 4s--5.5s is the interval where scroll attempt failed.
Additionally, I reloaded the page after it. We can see it in the log as another group of key events around 5.6s (it was Ctrl+R). Scroll attempt after it succeeded.

Deleted: trace_mouse-wheel-scroll (1).json.gz 2.0 MB

trace_mouse-wheel-scroll (1).json.gz 2.0 MB Download

I think I've found why it didn't happen on other people's environment.

It happens when using DELL MS111-P (USB mouse) which I have been using for about 5+ years.
I don't see the issue when using another new mouse, Logitech B100 (M-U0026).

Seems like an ordinary mouse - strange that would make a difference. Sahel, I have the exact mouse on my desk. Feel free to use it to try and repro when I'm not around.

Thanks, It helps.

I can reproduce this on 2 computers. I notice it especially happens when many resources are downloaded, which require a repaint of the page.

For example, on a dev site the issue appears when Open Sans Woff2 fonts are loaded and the text is adjusted. 

It also happens if some images are loaded in a later stage by lazy loading.

Scrolling stops, it's impossible to scroll. If I keep moving the scroll wheel, the scrolling simply doesn't work (indefinitely). Once I stop scrolling and wait a couple of seconds, the normal scroll behavior is restored.

Alright, I did some more testing: 

It seems the issue always happens when scrolling and an external resource is loaded. For example a google font, or an analytics tracking pixel. It also happens when external chat services are loaded on the page.

Although not 100% sure, it seems to be related to cross origin resource loading, which is rather strange.

Please check the following video:

https://www.dropbox.com/s/xijrjag39aufodp/2018-03-13_01-21-39.mp4?dl=0

I'm moving the mouse wheel the whole time, and the scrolling stops working when APP_ID is requested (from an external page).

Once I stop scrolling, the request to APP_ID is completed. It seems chrome is waiting for an available frame of some sort to complete the request.

Alright, so I have another video for the devs. 

I've added the following JS code to the page I was testing:

setTimeout(function(){
        window.requestAnimationFrame(function(){
            console.log('animationframe');
        })
    }, 5000)


Now check this video:

https://www.dropbox.com/s/5qub58878rit6lc/2018-03-13_01-47-12.mp4?dl=0

I've tried two times. On the first try scrolling keeps working but the callback method never get's executed until I stop. On the second try the scrolling stops working and the callback also doesn't work as long as I keep scrolling.

On both tries things return to normal once I stop scrolling.

I cannot reproduce the issue experienced by the thread starter. I can however reproduce what may be what #35 describes:

1) Navigate to http://faz.net
2) Start scrolling down immediately
3) Continue scrolling down if site gets stuck

The page should scroll for a bit, then get stuck, and then after a while continue scrolling after jumping down to presumably execute all missed scrolls.
This could indicate that these are separate issues.

I have found the cause of the issue in our particular case:

If an element with "position:fixed" is on the page, whether dynamically inserted or inside the HTML document from the start, the scrolling will stop at a certain point.

A workaround for this issue is adding the following CSS to the element with fixed position:

transform: translate3d(0, 0, 0);

This will cause GPU rendering to kick in for the element, which for some reason fixes the scrolling issue.

#38, you can probably fix the issue by adding the following style to your page:

.gh-MainNav {
  transform: translate3d(0,0,0);
}

This obviously is a bug in chrome, but I guess we'll have to work around it for now

I have fix for a similar bug and based on what you explained, the two bugs look the same, I hope to land the fix by tomorrow, meanwhile could you please check to see if https://chromium-review.googlesource.com/c/chromium/src/+/961264 fixes the issue or not?

I'm not sure how I can test this since I haven't done any development or chromium.

However, I do see that touchpad-scroll-impl-to-main.html does seem to reproduce this issue. 

It happens with sticky top menus like the test .html file simulates.

So I'm fairly confident a fix will work for this issue also :)

https://chromium-review.googlesource.com/961264 is a fix landed for a similar issue, yamaguchi@ could you please check to see if this fixes the regression or not?

I tried with 483aa2cc but still see the issue.
Chromium: 67.0.3377.0
Platform: 10402.0.0
Google_Caroline.7820.356.0

I can confirm this issue and a I also can confirm it for some colleagues in my company.

OS: Windows 7
Chrome: Version 65.0.3325.181 (Official Build) (64-Bit)
Mouse: Dell MS111-P (USB)
100% reproducable for example on this website: https://medium.com

The attached screenshot was produced by constantly scrolling down from the top of the page and clearly shows the interruption of the scrolling.

Deleted: scroll-bug.PNG 248 KB

	scroll-bug.PNG 248 KB View Download

same issue here, can reproduce it with the sample website, even on windows 10 and chrome 65

first i thought it's just a issue with chrome 65 + ubuntu 18.04 but now i have the same problems in windows 10 ...

Hey all,

We've spotted a few reports of this behavior in our Chromebook forum as well. During troubleshooting, our experts found that the following seem to cause the scrolling to (temporarily) begin working again:

- Touching the touchpad of your Chromebook
- Pressing the up or down key on your Chromebook

Just adding in case it helps pin down the root cause.

Thanks!

Have to state that I'm facing scrolling issues with the TOUCHPAD on an Acer CB5-571 since Version 65.0.3325.184 (Offizieller Build) (64-Bit), too.

Plattform
10323.62.0 (Official Build) stable-channel auron_yuna
Firmware
Google_Auron_yuna.6301.59.116
Kanal
Derzeit auf Stabil
ARC-Version
4660189

Issue only appears on random websites, Android apps are not showing an issue while scrolling. 

I have to release the touchpad and touch it again to scroll further.

 Issue 827505  has been merged into this issue.

I can confirm this issue in Arch Linux on a Thinkpad X230 (also T430) using TrackPoint scrolling (hold middle-button + move TrackPoint up/down).

https://bbs.archlinux.org/viewtopic.php?pid=1778092

The issue occurs on tabs seemingly randomly. Scrolling in that tab no longer works using the TrackPoint (does however seem to work with scroll wheels, etc.) until Refreshing the tab. The issue is confined to the affected tab.

When using a build with a potential fix, I am as yet unable to reproduce the issue again, but will continue testing for a day or so.

https://chromium-review.googlesource.com/c/chromium/src/+/961264

I can reproduce this on an HP Chromebook 13 on 64.0.3282.190 and beta 66.0.3359.67. It does not occur on Dev / 67.0.3381.0.

Well, after another day of testing, it does seem that using the "potential fix" (linked in previous post of mine) does not actually fix the issue. It "feels" as if it occurs less often (hard to say whether that's necessarily true), but does still occur.

I can confirm the issue is fixed on 67.0.3389.0 when scrolling while the page is already loaded.

However, when scrolling during page load (scroll up and down while refreshing the page), the scrolling still stops.

If "whether or not the page is loading" has an impact, it's probably relevant to mention that two of the pages I used to test were Twitter, and YouTube (comments), both of which dynamically load more content as you scroll.

Going through all the comments it seems like there are different issues here:

-If the bug goes away with disabling "Smooth Scrolling" from chrome://flags then it is related to 820979 which is fixed in M66.

-If the bug goes away with waiting for a while and then scrolling again, or moving the mouse more than 10 pixels and then scrolling again, then it is related to 828751 which is again fixed in M66.

yamaguchi@ could you please check ToT or the latest Canary to confirm if the issue in comment #0 still happens or not?

Issue is fixed for me in Version 66.0.3359.117 (Official Build) (64-Bit).

Issue was still reproduced on
Version 68.0.3397.0 (Official Build) unknown (64-bit)
Platform 10591.0.0 (Official Build) dev-channel eve test
Firmware Google_Eve.9584.18.0

The bug seems to be related to the scroll-by-moving functionality invoked by the middle-mouse-button.

I still experience the issue on 68.0.3405.0 Canary, and after a discussion at Google Product Forums, I've found a way to reproduce:

- middle-click on the page (not on a link) to invoke the move-mouse-to-scroll functionality,

- do not move,

- middle-click again to exit it.

Normal wheel scrolling should be broken after that.

To get it back at this point, invoke the functionality once more and then actually move to scroll, even a little, before leaving it again -- scrolling will work again.

Oh, I should mention: I'm experiencing this issue on Microsoft Windows 7, not Linux.

 egonfreeman@ the bug that you mentioned seems to be related to 829794.

I would like to confirm that the issue I am experiencing relates to the use of a ThinkPad TrackPoint (hold-middle-button-and-move scrolling), not the middle-click-THEN-scroll variety, which I thought was only available via an AutoScroll addon.

itspaafekuto@ seems like what you see is a separate issue that what is mentioned in comment #0, please file a new bug with steps to reproduce it.

yamaguchi@ (or anyone else who's experiencing this). Could you please capture another trace on the latest canary channel (68.0.3425.0 or newer). I've added more detailed information about scrolling to help narrow down the cause since we can't reproduce locally.

I could reproduce on linux latest build. Attached trace log.
Chromium: 68.0.3431.0
Revision: 583a90db90
commandline: out/Release/chrome --login-manager --show-component-extension-options
It stopped around 1 or 2 seconds before I hit the space key.
(I feel it's happening less frequently than before, as it sometimes took more than minutes of trials.)

Deleted: trace_3431-linux.json.gz 3.7 MB

trace_3431-linux.json.gz 3.7 MB Download

yamaguchi@ thanks for the trace.

 Issue 835827  has been merged into this issue.

The traces show that the scrolling gets stuck in smooth scrolling path,
GSU events get ignored since layer_tree_host_impl falsely thinks that there is an ongoing animation but fails to update it.

I am adding more traces to the cc animation to debug the issue further.

yamaguchi@ could you please mention when do you see the bug? Are scrolling the main frame or a div/iframe? and is it easier to reproduce it on any specific website?

I saw it when scrolling the main frame.
I still haven't found a site with which I can reproduce it easily.
Here are some examples that I could see repro.
- chrome://version
- chrome://drive-internals
- en.wikipedia.org/
However I still cannot see the specific pattern. Sometimes it happens after a few time of scrolling, but other time it doesn't happen until scrolling randomly for more than a minute.

I experience it mostly on Twitter. 

And yes, sometimes it occurs at the top of the page and I cannot srcoll at all. Sometimes I can scroll back for long minutes or even longer.

@yamaguchi 

For reproduction purposes try this link: https://www.amazon.ca/s/ref=sr_nr_n_1?fst=as%3Aoff&rh=n%3A6742111011%2Ck%3Aboard+games&keywords=board+games&ie=UTF8&qid=1524494392&rnid=526402301

On Windows I can reliably break it here if I start scrolling a lot as the page loads.

@sahel if we're merging 835827 into this one should the OS be upgraded to include Windows?

re comment #71:
Once the page loaded, can you normally scroll the page using mouse wheel? can you scroll after waiting for a second or moving the mouse? 

re comment #72:
yes, I forgot to do that, thanks

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

commit ca207e09127fb66ce6cdf09eff5f08fb2bac9dc0
Author: Sahel Sharify <sahel@chromium.org>
Date: Wed May 16 18:59:33 2018

Additional tracing in cc smooth scrolling path.

This cl adds tracing to answer the following questions to be able to
further narrow down the root cause of crbug.com/797708

-When did the last call to SetCurrentlyScrollingNode happen? (other than
on PushPropertyTrees after each commit)
-Is animation tick needed? (due to an ongoing animation)
-Whether the animation_host notifies the compositor about animation end
or not?
-When does the CurrentlyScrollingNode get cleared?

Bug: 797708
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I70f2295905798e430ce080c26f6924617504491b
Reviewed-on: https://chromium-review.googlesource.com/1060302
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559211}
[modify] https://crrev.com/ca207e09127fb66ce6cdf09eff5f08fb2bac9dc0/cc/animation/animation_host.cc
[modify] https://crrev.com/ca207e09127fb66ce6cdf09eff5f08fb2bac9dc0/cc/trees/layer_tree_host_impl.cc

CL in comment #74 adds new tracing for cc animation details and is first landed in 68.0.3433.0

yamaguchi@ could you please capture a trace with latest canary? Please make sure that cc and blink_animations are enabled.

Thanks

Attached trace on 68.0.3436.0.

Re: comment 71 and 73, I tried the URL but see as frequently as others.
In the page in the URL above, some additional contents load is triggered by scroll. However I saw I could scroll the page several times after the entire contents is loaded and seemingly stabilized. After continuing to scroll even more, I could reproduce the issue.

Deleted: trace_3436_0.json.gz 8.2 MB

trace_3436_0.json.gz 8.2 MB Download

yamaguchi@ thanks for the trace.

Starting from 7,567ms till 8,521.984ms the GSU events get ignored since compositor fails to update an ongoing animation:
https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?q=layer_tree_host_impl.cc&dr&l=3637

At 9,211.850ms and 9,827.157ms two GSB events get ignored since compositor fails to create animation:
https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?q=layer_tree_host_impl.cc&dr&l=3519

When a GSB gets ignored all the GSU events in the sequence get ignored as well and that's why the GSU events after 9,211.850ms gets ignored.

I need to add more tracing to see why ScrollAnimationUpdateTarget returns false.

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

commit c7ee7dd261fbc9a68e612a777bdd912fcd500662
Author: Sahel Sharify <sahel@chromium.org>
Date: Fri May 25 23:25:59 2018

Add more cc animation tracing.

This cl adds tracing to see why ScrollAnimationUpdateTarget returns false.

Bug: 797708
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I40b0e2b71d25ddaa4a0d685cfb223bd83dd8f1b2
Reviewed-on: https://chromium-review.googlesource.com/1073754
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562057}
[modify] https://crrev.com/c7ee7dd261fbc9a68e612a777bdd912fcd500662/cc/animation/scroll_offset_animations_impl.cc

Thanks, sahel@.

I've opened a new ticket #847153 which exclusively describes the ThinkPad TrackPoint scrolling issue.

yamaguchi@ could you please capture a new trace since with what landed in comment #78 we capture more information about the status of compositor animation.

Captured on 69.0.3444.0.

Just in case we need to capture data once again, do you need the trace capture started before the bug is triggered, or can the capture be started after the bug happened?
(this data is taken by the former way.)

Deleted: trace_3444.json.gz 8.2 MB

trace_3444.json.gz 8.2 MB Download

I am having problems with scrolling with my Logitech mouse, wireless on my Samsung Chromebook...it is new after using this for several years...I'm told it's a bug!

Google Chrome	66.0.3359.181 (Official Build) (64-bit)
Revision	0
Platform	10452.96.0 (Official Build) stable-channel winky
Firmware Version	Google_Winky.5216.265.53
JavaScript	V8 6.6.346.32

Based on the trace in comment #81 it looks like the first time that cc fails to update the scroll animation happens here:
https://cs.chromium.org/chromium/src/cc/animation/scroll_offset_animations_impl.cc?type=cs&sq=package:chromium&g=0&l=80
and after Detaching the element for the rest of the ignored scrolls the animation update fails here:
https://cs.chromium.org/chromium/src/cc/animation/scroll_offset_animations_impl.cc?type=cs&sq=package:chromium&g=0&l=70

The only possible explanation that I have is some sort of a race when a GSU arrives at the exact frame that the animation is going to finish, I will add more tracing information to verify this.

yamaguchi@ thanks for the traces and being responsive on the issue, I really appreciate it. We want to find out why/how does the scrolling get to the bad state. Once the scrolling is stuck in the bad state we know why it doesn't work, So a trace that has started before the bug is triggered is useful. 

re comment #82:
nchealth4000@  since you see the issue using an external mouse with your chromebook most likely what you see is related to one of the following two bugs which are both fixed in M67:
 crbug.com/817479 
 crbug.com/838457 

Please wait for the M67 version(will be released at June 5th) and file a separate bug if you can still see the issue.

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.

Issue 807689 has been merged into this issue.

Issue 807689 is related to autoscroll rather than smooth scrolling, not a duplicate of this bug.

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

commit ee909721233bd592bb427432055cf7953c68afbc
Author: Sahel Sharify <sahel@chromium.org>
Date: Mon Jun 11 18:33:43 2018

Add duration of scroll animation to cc tracing.

This cl adds the duration of scroll animation to tracing. The new
information helps with finding out the root cause of the potential race
in smooth scrolling path.

Bug: 797708
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic30ad116bf8dc8047d10ab66cf4c45618d0dee27
Reviewed-on: https://chromium-review.googlesource.com/1093539
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566072}
[modify] https://crrev.com/ee909721233bd592bb427432055cf7953c68afbc/cc/animation/scroll_offset_animations_impl.cc

Loaded chrome://flags/#overlay-scrollbars, clicked "Disable".  Problem goes away.  We have a dozen Chromebooks, all behave the same. I'm worried that if this flag is gotten rid of, I won't be able to use our Chromebooks in our business setting.

Re#89, I suspect that may be a separate issue. We've narrowed this one down to a problem in smooth scroll animations and it's occurring on platforms where overlay scrollbars aren't used.

Please file a new bug (cc me) and we can follow up there.

 Issue 854244  has been merged into this issue.

yamaguchi@ could you please capture a new trace (comment #88 adds new tracing info)? Please make sure that input_latency, cc and blink_animations are enabled.

Captured on: 69.0.3475.0 / Google_Caroline.7820.356.0

Deleted: trace_Fri_Jun_29_2018_19.17.05.json.gz 2.8 MB

trace_Fri_Jun_29_2018_19.17.05.json.gz 2.8 MB Download

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

commit 7e9dea0b1588aac4a270019ad38d269f1905bb56
Author: Sahel Sharify <sahel@chromium.org>
Date: Mon Jul 30 16:52:26 2018

More detailed tracing for smooth scrolling.

This cl adds additional tracing for smooth scrolling path in cc. A
NOTREACHED is also added to the invalid case that the scrolling node
exists in layer tree host impl, but the animation update fails.

Bug: 797708
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If17af64781e78d02f09433e1c0e479231e69b4c2
Reviewed-on: https://chromium-review.googlesource.com/1145736
Reviewed-by: weiliangc <weiliangc@chromium.org>
Commit-Queue: Sahel Sharify <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579069}
[modify] https://crrev.com/7e9dea0b1588aac4a270019ad38d269f1905bb56/cc/animation/scroll_offset_animations_impl.cc
[modify] https://crrev.com/7e9dea0b1588aac4a270019ad38d269f1905bb56/cc/trees/layer_tree_host_impl.cc

Ping - sahel@, any updates on this bug?

My previous patch has a NOTREACHED, as we discussed I am gonna change it to CHECK to force crashes when layer_tree_host_impl falsely assumes there is an active scroll animation. I'd prefer to do it once I am back from ooo to be able to process the crashes and get rid of the CHECK asap.

The NextAction date has arrived: 2018-09-12

sahel@: you can dump a stack without causing a crash (as CHECK does) using DumpWithoutCrashing. See https://chromium-review.googlesource.com/c/chromium/src/+/1185872 for an example.

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

commit 5665173d7b24c8b8bba8af94d0eebfdf0ab38a13
Author: Sahel Sharify <sahel@chromium.org>
Date: Fri Sep 14 16:57:43 2018

Use of dump without crashing to debug smooth scroll animation bug.

Bug: 797708
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Icce9d0c3eeed94297936aebc81681f5db2ec0682
Reviewed-on: https://chromium-review.googlesource.com/1226825
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sahel Sharify <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591377}
[modify] https://crrev.com/5665173d7b24c8b8bba8af94d0eebfdf0ab38a13/cc/trees/layer_tree_host_impl.cc

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

commit 817d93d062e4a46fb34205ef124ee3950a5dbceb
Author: Sahel Sharify <sahel@chromium.org>
Date: Wed Sep 19 15:31:30 2018

Revert "Use of dump without crashing to debug smooth scroll animation bug."

This reverts commit 5665173d7b24c8b8bba8af94d0eebfdf0ab38a13.

Reason for revert: this is ranked as #1 renderer process related crash on the latest chrome dev 71.0.3554.0 on Windows. 97 crashes from 90 clients so far.

Original change's description:
> Use of dump without crashing to debug smooth scroll animation bug.
> 
> Bug: 797708
> Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Icce9d0c3eeed94297936aebc81681f5db2ec0682
> Reviewed-on: https://chromium-review.googlesource.com/1226825
> Reviewed-by: David Bokan <bokan@chromium.org>
> Commit-Queue: Sahel Sharify <sahel@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#591377}

TBR=bokan@chromium.org,sahel@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 797708, 884592
Change-Id: I1e2787982eb1920e28e9a38281de0c76334162f2
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/1233954
Reviewed-by: Sahel Sharify <sahel@chromium.org>
Commit-Queue: Sahel Sharify <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592409}
[modify] https://crrev.com/817d93d062e4a46fb34205ef124ee3950a5dbceb/cc/trees/layer_tree_host_impl.cc

Is there any update for this? I have around 2 dozen ASUS Chrome Boxes and we use a web based tool that involves a lot of scrolling and we get this bug on a daily basis. I've had to resort to either pushing a scrolling extension, or manually walking around and disabling the #overlay-scrollbars flag. Which is annoying because apparently you can't do this through G Suite policy since flags are 'experimental features', so why are they being pushed to stable release channels then?

Deleted comment #104 since I misunderstood the comment #103 and thought the issue is related to the overlay-scrollbars.

I am working on the issue, it is slower that expected since I cannot repo the issue locally, I'll do my best to get the fix on our next stable release (M71)

carter.rohan.wilson@ could you please check the issue goes away by disabling smooth-scrolling from chrome flags or not?
-Are the are any steps that consistently repo the issue?
-Any sample URLs?

Also have this issue on Ubuntu 18.04, with Gnome desktop, using latest Chrome stable and a Wacom tablet (instead of a mouse), especially on certain pages in Google Search Console web pages. Disabling #smooth-scrolling flag did not solve the issue.

I found that my issue was a scrolling wheel not behaving properly, I changed the mouse and it was fixed.

Is this related to the "2 finger trackpad scrolling stops working" bug here:

https://bugs.chromium.org/p/chromium/issues/detail?id=647038

I can confirm that this bug is not scroll wheel only. I have the same problem on Surfacebook 2 using 2 finger scroll. 

@  sahel@chromium.org My mistake as well, after some further troubleshooting I can confirm that disabling the #smooth-scrolling flag alone resolves our issue. Unfortunately the URL we are using is an internal company tool, but I can tell you the page has divs/iframes inside that are scrollable as well.

When the scrolling breaks the user can still scroll with keyboard shortcuts and opening a new tab and loading the page again will fix it.

It is difficult to reproduce on the spot, but since the users are in this environment for 8 hours a day it happens frequently enough that it is a problem.

This problem still persists in Version 71.0.3578.80 (Official Build) unknown (64-bit) on Ubuntu 18.04.

I've been playing around with capturing the `wheel` event and conditionally calling the `event.preventDefault()` when I calculate that the `wheel` event won't result in an scrolling on the container. I am not sure if this if "fixing" the issue, per say; but, I don't seem to be able to reproduce the problem when I use this technique. If anyone is interested:

https://www.bennadel.com/blog/3544-trapping-the-wheel-event-may-prevent-chrome-browser-bug-in-which-the-scroll-wheel-stops-working-in-overflow-container.htm

Of course, there is a performance down-side to tapping into the `wheel` event. But, it may be an interim trade-off.

Recomment #113: Calling preventDefault when wheel won't cause scrolling is not a fix and it changes the scroll propagation behavior: When the element receiving the wheel event cannot scroll in the given direction the scroll propagates to the first element in the chain that can consume deltas in the given direction. Calling preventDefault in addition to performance penalties prevents scroll propagation.

I am working on this issue to find a fix. Our target is 73

I'd just like to say that this is also a problem for me using 71.0.3578.98 on a Dell XPS 13 with Windows 10. I use a trackpad with two-finger scroll, and multiple times a day the scrolling function will completely stop working while I'm using a tab. The only way for me to correct this is to switch to a different tab and then return, or to refresh the tab that's broken. I've tried all the obvious stuff like reinstalling, trying without any extensions installed, turning off various relevant flags. nothing has helped!

I would like to just give my feedback on this, I'm using a Logitech M720 over bluetooth, this issue happens on Chrome randomly but not on the other applications (I'm on Windows 10 October Update with Chrome 71.0.3578.98).

I found on my side that if I disable the smooth scrolling on Logtitech Application, everything starts working again, if I enable smooth scrolling it doesn't work on Chrome.

Deleted: LT-M720.png 60.1 KB

	LT-M720.png 60.1 KB View Download