The bug tracking enabling these by default was issue 307091 -> assigning to bokan@ and cc'ing jennschen@.

+Design and PM

Are you talking about what's attached (click the M). I was able to navigate it just fine.

If you are talking about the tracing itself that you can navigate using drag I indeed wasn't able to grab the overlay scrollbar.

Deleted: Screenshot 2018-01-12 at 12.30.32 PM.png 493 KB

	Screenshot 2018-01-12 at 12.30.32 PM.png 493 KB View Download

Re #3: The tracing example was just an example; in general I've found overlay scrollbars to have extremely poor usability across a variety of sites:

- They "hide", and can be very hard to get to "show" especially if they are at the edge of the screen, when auto-hiding toolbars, or multiple monitors, are in-use.
- Sometimes they "hide" to be completely invisible, and won't then show until you manage to trigger a scroll operation via some other means.
- Again, because they hide & show, they are a moving target, making them hard to hit.
- They often just don't work, as in this case.

Looking at the launch bug, it looks like overlay scrollbars were pushed to ChromeOS to suit tablet form-factor devices, i.e. their design assumes a touch-screen device, which is not generally the case, and may explain why these issues weren't addressed?

FYI, there is a recent regression (again) making overlay scrollbar untouchable again on all platforms that has overlay scrollbar enabled either by default or via the flag. (e.g.  issue 799150 )
You may want to keep the regression in mind when you address this bug.

Regarding the cases where you can't interact with scrollbars: there are some known issues (e.g.  issue 715742 ,  issue 778992 ). The expectation was that these cases were relatively uncommon and, combined with stats that a minority of scrolls are done by interacting with scrollbars, meant that it would be rarely encountered. It's possible we underestimated how common these cases can be.

Unfortunately, they're the result of some deep decisions about how compositing and painting are done in Chrome. These can affect Mac overlay scrollbars (as seen in #6) too in certain situations. Scrollbars are currently being redesigned for the Slimming Paint project which should address these issues but that's likely a few milestones away.

Re #7: I filed this bug basically because overlay scrollbars are painful with most sites, and seemingly unusable with a few of the sites I use regularly - I primarily use a Chromebox, so am limited to mouse input, no touch, which may put me in a ChromeOS-user minority.

My recommendation would be to disable overlay scrollbars under ChromeOS, at least for non-touch devices, until whatever new hotness is in the works is ready.

Chromebox was one of the cases we thought might be uncommon but a bit painful. One option that was floated was to switch to non-overlay when an external mouse is plugged in (similar to how Mac does it). At the time we decided to punt on the decision. Gabriel, Tom, maybe we should reevaluate?

Re #9: That would be ideal for my use-case (although TBH I don't find overlay scrollbars as usable even in touch mode, but I suspect getting rid of them entirely on CrOS would be a harder sell ;)

Re #9: Also note that the overlay scrollbars are also painful when navigating via trackpad on any other ChromeOS device, including both the non-touch and touch-enabled versions - it's not specific to folks w/ a mouse connected.  Perhaps trigger based on whether mouse input events have been processed?

Overlay scrollbars aren't meant just for touch scenarios. While they're a little less convenient when using the mouse to move the scrollbar, we've collected statistics that showed that was fairly rare[1]. The expectation is that users "two-finger" scroll on trackpad devices or use the mouse wheel (assuming they have one - granted not all mice have a wheel).

This will often boil down to personal preference - I've argued for adding a setting (as Mac does) but we're generally quite averse to that. Until then, chrome://flags/#overlay-scrollbars works.

[1] issue 688193

Re #12: The stats gathered on issue 688193 appear to consider usage only as %age-of-pageviews, rather than %age usage given content which is actually scrollable, which seems a substantial bias to the results, surely?  For example, most pages don't have any horizontal scrolling, only vertical, so the fact that the %ages there are tiny is highly misleading - basically making the argument that very little content needs horizontal scrolling, so having working scrollbars isn't important.

For example, if you instead look at ScrollByTouch vs ScrollByWheel stats, you'll see that ScrollByWheel is ~2x the %age usage of ScrollByTouch - but wheel scroll is only available for vertical scrolling for a substantial portion of users.

More fundamentally, though, the data in issue 688193 doesn't really seem relevant to the question at hand. An argument that "barely anyone uses scrollbars" (and at ~6% of pageviews I don't agree with that assessment, especially not without a %age-of-pageviews-of-scrollable-content correction) is conflating breadth of impact across the user population with depth of impact on individual users. If you are in the small %age of users needing to use scrollbars, then you need them to work; just because 94% of pageviews don't use them doesn't mean they can be 94% less functional. :)

> rather than %age usage given content which is actually scrollable, which seems a substantial bias to the results, surely?

That's true - eliminating that bias isn't simple though unless you look just at the main frame which would introduce it's own biases.

> An argument that "barely anyone uses scrollbars"...

Sorry, I didn't mean to sound dismissive as ~6% of page loads is still significant. I just meant we should optimize for the most common case and mouse interaction with the scrollbar is still supported (though perhaps more buggy than we realized). Your point about breadth vs depth of impact is well taken.

From the bugs and online forums I've seen, many of the users who complained about issues were using an external mouse/chromebox. sgabriel@, can we revisit adding in the "use non-overlay" mode when an external mouse is present? That could be landed quickly and should help the most-impacted users.

Yes, worth a shot, @Tom can you check with Ui-review as well?

Re #14: No problem, I didn't think you were being dismissive, I just disagreed with the analysis; I appreciate that it's hard to concoct good usage metrics without introducing other kinds of skew.

Thanks for acting promptly on this feedback. :)

Incidentally, should we de-dupe this with  issue 688192 , or is it better to keep it to track the specific usability issues preventing more widespread overlay scrollbar deployment?

Do you mean if we _should_ dup it into 688192 (since nothing's dup'd here).  Issue 688192  is quite different from this issue IMHO so I'm happy to keep this separate.

As a concrete example from around the web, scrolling TweetDeck horizontally to view all my configured timelines on my Chromebox is nearly impossible with the current overlay scrollbar behavior in 65.0.3319.0. My mouse does support scrolling horizontally by pushing the scroll wheel left/right but it's much slower than dragging the scroll handle.

ping, tbuckley@: can you check with UI-review re:#14?

sgabriel@: can you follow up with UI-review?

We'd also need an engineer from the ChromeOS-side to do the plumbing into Blink (similar to how it happens on Mac: OS settings change causes a call into RenderThreadImpl::UpdateScrollbarTheme with new settings).

I can provide the required Blink-side changes.

Email has been sent to UI-review. 
We'll act on this depending on the outcome of the discussion.

Thanks, in the mean time I'll see if anything can be done about the problematic cases in the short term.

So it looks like we're not going to explore adding regular scrollbars in just yet.

We need to fix the hover behavior first to enable grabbing horizontal scrollbars without problem.

Re #23: Can you clarify what you mean by "explore adding regular scrollbars in"?

My proposal as a resolution to this bug was just to revert to the standard scrollbars, so that ChromeOS devices are usable with mouse and trackpad. Standard scrollbars are in use on the other desktop-ish platforms, and were previously in use on ChromeOS as well.

Sorry bad phrasing.
Meant to say we're not going to revert to standard scrollbars at the moment. 

OK, can you elaborate as to why we aren't going to do that?

bokan's suggestion was to do that only while an external pointing device is
connected, i.e. not a revert, just an automatic run-time switch. What's the
problem with that?

Quoting UI-review:

"We did previously talk about having a separate behavior for mice the last go-around, but think there's some futzing with the hover-to-grab timing and behavior here worth trying first (e.g. reducing delays) and would like the team to go down that route before re-opening the mouse-vs-touchpad scrollbars conversation."

Some discussion are still ongoing. Will post updates as needed.

Is it better to file bugs for specific sites on which the current behavior leads to a broken experience or collect those examples here?

Collecting here would be better so that we can centralize the discussion.

That or mark the bugs as blocking this one.

Just for record. Don't know what have been done between 67.0.3386.1, but in the latest Dev version 67.0.3394.4 overlay scrollbars become quite responsive even in a complicated layout like TweetDeck. (previously on such pages overlay scrollbar could only be summoned by doing a scrolling)

Leaving a checkpoint here so in the event of future regression we can track what once made overlay scrollbars awesome, maybe.