The labels are a little confusing, Blink>Layout>Scroll is for layout of the scrollbar itself and for issues where a scrollbar shows up/doesn't show up unexpectedly.

Blink>Scroll is for scrolling and Blink>Input for interacting with a scrollbar.

Moving to Blink>Scroll for further triage.

Just to confirm, this is with overlay scrollbars when you enable from chrome://flags right? We're not shipping these to stable yet.

In M57 we are adding stats around scrolls triggered by drags on the scrollbar and clicks on the track.

Moving overlay scrollbar bugs to M59

Some data from our newly added stats in ChromeOS Stable [1].

Out of 2,239,922,938 page views we have:

UseCounter name                         Count          ~Percentage of Page Views having used this
===============================================================
ScrollbarUseVerticalScrollbarButton	219,686        0.01%
ScrollbarUseVerticalScrollbarThumb	106,041,050    4.73%
ScrollbarUseVerticalScrollbarTrack	38,735,555     1.72%
ScrollbarUseHorizontalScrollbarButton	24,622         0.00%
ScrollbarUseHorizontalScrollbarThumb	1,304,101      0.06%      
ScrollbarUseHorizontalScrollbarTrack	233,587        0.01%


To me this says barely anyone uses scrollbars, but of those who do, most drag and a significant portion use the track, more than I would have guessed.

Tom, Sebastien, are there any concerns from this data?

[1] https://uma.googleplex.com/histograms?endDate=20170627&dayCount=7&histograms=Blink.UseCounter.Features&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

Ping, Tom/Sebastien, is there anything actionable here or should we WontFix?

Easy answer to this would be to show track on hover. 
I believe we decided not to show one for reason that I cannot clearly remember at the moment. Tom? did we find a downside of having a track only on hover ?