Sorry but I still cannot reproduce this. Can you walk me through step-by-step?

Here's what I'm doing:
1) Sign in to twitter
2) Visit https://twitter.com/TrueCar
3) Click the tweet "TrueCar is ending its car buying service relationship with the NRA effective February 28, 2018."
4) Scroll with the mouse wheel.

For me, everything works as it should; are these the same steps you're doing? I'm using a blank profile with no extensions and no about:flags settings changed. Can you try in an incognito window just to make sure it's not an extension?

I think the issue only arise if starts from your twitter timeline, if I sign in into twitter and visit https://twitter.com/TrueCar the issue is no longer reproduced. You have to start from your timeline and find some tweet with enough replies to "induce" a scroll.

I did reproduce with incognito mode. The only flag I did enable is "Strict site isolation". 

(I did also try with an "invited user" and I can still reproduce).

Tell me if you need some more informations (launch with debug log or try with canary).

*if you start from

I'm still not able to reproduce :/

Can you try to reproduce on another machine?

Can you go to about:gpu, file->save as, then attach the resulting file here?

Here's my about:gpu. I will try to reproduce on a mac an report back.

I found something interesting: 
 - 2 errors were generated in about:cpu log after reproduction
 - If I try to reproduce when being on the top of the page, the scroll is not blocked. But if I scroll a little an retry with the same tweet, the scroll is locked

I also made some screencast showing the issue, the 3 times I open the tweet and scroll. Notice the stuck scrollbar at the end.

Deleted: gpu.html 67.4 KB

gpu.html 67.4 KB View Download

Deleted: demo.mp4 9.2 MB

	demo.mp4 9.2 MB View Download

So I was able to reproduce on a Mac (OSX High Sierra 10.13.3) with chrome 66.0.3350.0. 

Steps used:
 - open chrome
 - browse to https://www.twitter.com/BBC
 - scroll down a little (with the touchpad) until the content is just at the top of the BBC logo and click on the pinned tweet

Unable to reproduce the issue on chrome reported version 66.0.3350.0 using Ubuntu 17.10 with steps mentioned below:
1) Launched chrome reported version and navigated to twitter
2) Selected a tweet which has some answers and clicked on it
3) Scrolled up and down with the mouse, didn't seen any "broken in scroll or scrollbar thumb strucked at the top"
Observation: As per comment#7, tested with the URL provided in Mac 10.13.3 on 66.0.3350.0, unable to reproduce the issue on it.

@Reporter:
Please find the attached screencasts of both Unbuntu 17.10 and Mac 10.13.3 for your reference and let us know if we missed anything in reproducing the issue, attached is the GPU of Linux and Mac. Provide your input on it which helps us in further triaging it.

Thanks!

Deleted: Linux-816660.mp4 2.6 MB

	Linux-816660.mp4 2.6 MB View Download

Deleted: Linux-GPU.pdf 104 KB

Linux-GPU.pdf 104 KB Download

Deleted: Mac-816660.mp4 3.2 MB

	Mac-816660.mp4 3.2 MB View Download

Deleted: Mac-GPU.pdf 104 KB

Mac-GPU.pdf 104 KB Download

@viswa.karala, thanks for your time.

It looks like you are doing what I do, as far as I can tell. I don't know what I can provide to help you figure out where the issue is. I did run chrome on my mac with --enable-logging --v=1, but I don't see anything special in the logs. 
I did notice that when the scroll is stuck, I can "unstuck" it if I'm able to scroll up the parent 

If there's some kind of "debugging" I can perform, please tell me. Do you want me to try to reproduce with a canary build?

Thank you for providing more feedback. Adding the requester to the cc list.

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

Reporter, if you have "Experimental Web Platform features" enabled in chrome://flags, it may be caused by https://crrev.com/530927 in which case you can disable the "bug" by running chrome --disable-blink-features=ImplicitRootScroller

(#c2 says you don't have that flag enabled but give it a try anyway - restart chrome with the command line in #c11).

@woxxom: Thanks, did try with the flag and the issue is still here with it. I get a message saying "You are using an unsupported command-line flag: --disable-blink-features=ImplicitRootScroller..." on top of my browser window.

Playing with flags related to scroll I found the issue gets fixed with chrome://flags/#disable-threaded-scrolling disabled. (NB: the end of the tweet is missing as in #813835, but that's expected I think). 
Will try this flag when I get back to my linux machine and report back.

(tested on OSX)

Back to report results on Linux, with chrome://flags/#disable-threaded-scrolling disabled the issue is gone. 
I hope that helps.

Using the video in comment #6, I was able to reproduce this on linux.

I bisected this down to:
https://chromium.googlesource.com/chromium/src/+log/44f1b3b89106e19e067e6076d890193f2dd5f428..dd421690f914a20eb2893c6377b32f10aa2bbfe6

Almost certainly "Enable root layer scrolling."

Here are my repro steps:
1) go to twitter.com
2) resize window to about 600px high, width doesn't matter
3) login to a twitter account that has some subscriptions. Contact me if you'd like test login creds.
4) scroll the main feed down.
5) click some tweet thread.
6) put mouse in grey gutter and try mouse-wheel scrolling. The page does not scroll.

I'll look at this.

Minimization:
http://output.jsbin.com/bopesex/quiet

With RLS, the compositor-thread hit test fails to see the fixed-position overflow scroller.

Repro requires --disable-prefer-compositing-to-lcd-text on high DPI (but the scroller is composited due to a transformed descendant).

This is a general problem of not updating non-fast scrollable regions inside a composited scroller.

Here is a repro without RLS (and independent of high DPI):
http://output.jsbin.com/parenod/quiet

I also encountered this a while ago on  issue 596979 .

Does this mean that we should be calling ScrollingCoordinator::ComputeTouchEventTargetRects on every scroll update of a composited scroller?  That will almost certainly have a big impact on performance.

Unable to reproduce the issue on chrome reported version 66.0.3350.0 using Ubuntu 17.10 with steps mentioned below:
1) Launched chrome reported version and navigated to twitter
2) Selected a tweet which has some answers and clicked on it
3) Scrolled up and down with the mouse, checked the scrolling behaviour three times by changing the position of the tweet 
4) Didn't seen any "broken in scroll or scrollbar thumb strucked at the top"
Hence removing Needs-Bisect label, please feel free to add if required.

@Reporter:
Please find the attached screencast for your reference, attached is the GPU details.

Thanks!

Deleted: 816660.mp4 2.4 MB

	816660.mp4 2.4 MB View Download

Deleted: GPU.pdf 104 KB

GPU.pdf 104 KB Download

IIRC the rects are in content-space so they shouldn't need to change on scroll. +wjmaclean@ who's currently plugging holes in the non-fast-scroll-rects code for more info.

Re #21: the problem is that the non-fast scroller is position:fixed, so its location in document-content space does need to change when the document scrolls.

Non-fast scroll regions are stored on the layout viewport scrolling content layer but computed by PLSA::ScrollableAreaBoundingBox which returns absolute coordinates.

Here's an even simpler repro without position:fixed and without composited descendants (does require low DPI):
http://output.jsbin.com/kumabot/quiet

skobes@ - bokan@ has suggested changes to that function which I have in a CL at https://chromium-review.googlesource.com/c/chromium/src/+/922421

It would be interesting to see if that helps with this issue.

wjmaclean: yes it looks like your patch mostly fixes this bug.  Do you expect it to land soon?

We still fail to update the non-fast scroll region after an overflow scroll, but fixing the coordinate space is a necessary first step that may unblock the RLS launch.

Issue 813765 has been merged into this issue.

re #25: Yes, I have LGTMs, just doing a little more local testing first (and I just submitted a CL to disable a flakey test that was causing grief too ...).

It looks like http://crrev.com/c/922421 fixes the original report on twitter.com, as well as the repros in #17 and #23.

It doesn't fix #18, or a trivial variation on #17:
http://output.jsbin.com/vivehez/quiet

But these are already broken without RLS, so I'm considering them out of scope for this bug.

Filed issue 817600 for the problem of not updating the non-fast scroll region after a scroll occurs.

Verified this and issue 813765 are fixed at r539959.