Just check Chrome on Mac and Safari on Mac. Mac overlay scrollbar always begin with hide for container with overflow:auto or overflow:scroll. bokan@ WDYT?

For OSX, there is a system setting for this:
http://osxdaily.com/2011/08/03/show-scroll-bars-mac-os-x-lion/

This is intended behavior. The overlay behavior is well established on Android/Mac and is generally ok since the scrollbars fade out fairly quickly, showing the content below. The attached case actually feels ok to me from that point of view.

We may need to adjust the timing if they don't fade out quickly enough but I don't think the linked bug is special in any way that general web content isn't. 

One area that the linked bug in gerrit does feel a little worse is horizontal scrolling. It's not discoverable and with a wheel requires the user know that "shift+wheel" scrolls horizontally. +tbuckley@, +sgabriel@ for thoughts.

For Mac, it's possible to disable this behavior with a system setting.
Is there similar one for ChromeOS?

No, it's been discussed but UX review generally dislikes adding options and didn't feel overlay scrollbars warranted one.

But that's related to user preference rather than web content - the page can't choose to use a non-overlay scrollbar even on OSX.

Just FYI, here's the original report:
https://bugs.chromium.org/p/gerrit/issues/detail?id=5964

> page can't choose to use a non-overlay scrollbar even on OSX.

It seems the only option to solve the original bug is to use hacks to detect scrollbar style (inside or outside) and add margin.

For the case in original report, can you move mouse away the scrollbar, wait for it fade out then comment on the line?

I've tried that, and here's the difference from OSX behavior:

For OSX, the scrollbar only appears on scroll. So mouse-over, click etc doesn't bring the scrollbar up and obscure diff content.

For ChromeOS dev channel, scrollbar appears on mouse-over too. So, unless user click content within 1 sec, scrollbar obscures diff.
Detailed steps:
1. Scroll the container
2. Move mouse out
3. Move mouse over the place where the scrollbar should be (last line)
4. Wait, don't click/scroll
5. in ~1 sec, scrollbar appears

I've tried to record a video, but could find good tool for that on Chromebook, and phone video was a potato :(

Yeah, if you need to interact with something under the scrollbar the experience may not be ideal. Perhaps we need to adjust the timing?

FYI: this sounds like the ideal use case for the newly proposed scrollbar-gutter property, implementing it is being tracked in issue 710214 (though it's likely long term enough not to be of use to you yet)

> Perhaps we need to adjust the timing?

For OSX, scrollbar never appears on mouse-over, unless is visible already after scroll.

I'm sure ChromeOS did extensive UX studies, and I'll leave difference in scrolling behavior for your discretion.

But as of now, we simply can't keep current behavior. 
It effectively prevents people from selecting text on last line of the diff, so we'll have to implement ChromeOS-dev-channel-specific workaround.

Thinking about this some more, I think we should prevent showing the scrollbars if the user is interacting with the content. i.e. if the user clicks or starts selecting text the scrollbar shouldn't fade in - or at least we should reset the timer.

Makes sense to me.

Is it better we also reset fade-in timer when user moving inside the hover-fade-in-area?

For #12, is it only for hover fade-in behavior? Should we do same thing for mousedown(selecting) and scroll?

I think if we do it on mouse move, it'll be difficult to trigger the scrollbars since holding the mouse perfectly steady isn't super easy (at least for everyone). I think if we just prevent showing the scrollbars while the mouse is down (i.e. the user is selecting text or doing something else there) that should be enough.

As for your second question, lets start with just changing the behavior for hover. Scrolling should always fade-in the scrollbars, even if the user is selecting text while scrolling, I don't think scrollbars can get in the way in that scenario.

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

commit ac6ccd29b4eaa1e056c0cd0656e2fad8aa624d42
Author: chaopeng <chaopeng@chromium.org>
Date: Mon Jun 12 20:03:41 2017

Don't fade in overlay scrollbar when user interacting the content under scrollbar.

The issue ( crbug.com/719011 ) indicate that it is hard to interact with
the content under the the scrollbar because the scrollbar will fade in
while mouse moves in the hover fade in region of scrollbar.

In this patch, we prevent fade in overlay scrollbar when user mouse
down. 3 behaviors changed:

1. When mouse move in hover fade in region of scrollbar with mouse
   press, we don't trigger delay fade in.
2. When mouse down after a delay fade in triggered, cancel the delay
   fade in.
3. When mouse up in hover fade in region of scrollbar, trigger a delay
   fade in.

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

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

[modify] https://crrev.com/ac6ccd29b4eaa1e056c0cd0656e2fad8aa624d42/cc/input/scrollbar_animation_controller.cc
[modify] https://crrev.com/ac6ccd29b4eaa1e056c0cd0656e2fad8aa624d42/cc/input/scrollbar_animation_controller.h
[modify] https://crrev.com/ac6ccd29b4eaa1e056c0cd0656e2fad8aa624d42/cc/input/scrollbar_animation_controller_unittest.cc

Confirmed fix in Dev Channel on Linux. I think this is important for the scrollbar launch, lets merge back to M60.

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

For context: this is a usability fix for Chrome OS overlay scrollbars, which are launching in M61. 

Any reason to merge-request for M60 if this is launching on M61?

Sorry, I mistyped above. Overlay scrollbars are launching in M60 and are currently turned on in the beta channel so we'd like the fix in M60.

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

commit ec0cede7db7fada94b0d69a44d7f0e6c138ee877
Author: David Bokan <bokan@chromium.org>
Date: Tue Jun 27 15:21:26 2017

Don't fade in overlay scrollbar when user interacting the content under scrollbar.

The issue ( crbug.com/719011 ) indicate that it is hard to interact with
the content under the the scrollbar because the scrollbar will fade in
while mouse moves in the hover fade in region of scrollbar.

In this patch, we prevent fade in overlay scrollbar when user mouse
down. 3 behaviors changed:

1. When mouse move in hover fade in region of scrollbar with mouse
   press, we don't trigger delay fade in.
2. When mouse down after a delay fade in triggered, cancel the delay
   fade in.
3. When mouse up in hover fade in region of scrollbar, trigger a delay
   fade in.

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

Review-Url: https://codereview.chromium.org/2931703002
Cr-Original-Commit-Position: refs/heads/master@{#478733}
Review-Url: https://codereview.chromium.org/2957093003 .
Cr-Commit-Position: refs/branch-heads/3112@{#478}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/ec0cede7db7fada94b0d69a44d7f0e6c138ee877/cc/input/scrollbar_animation_controller.cc
[modify] https://crrev.com/ec0cede7db7fada94b0d69a44d7f0e6c138ee877/cc/input/scrollbar_animation_controller.h
[modify] https://crrev.com/ec0cede7db7fada94b0d69a44d7f0e6c138ee877/cc/input/scrollbar_animation_controller_unittest.cc

Merged back to M60 (branch 3112)