This was tested on several different Samsung Android (v5.1+) tablets, with the same results.  My specific test (that I probably should have put in the steps above) was to create a simple page using the code here:

http://cssdeck.com/labs/css3-webkit-vertical-scrollbars/

The scrollbars appear in Android System WebView version 54 but not in version 55.

Over to webview team for further triage.

I confirm ::-webkit-scrollbar still appears to work in Chrome 55 on Android, not sure why it would be broken in WebKit specifically, so yeah we probably need a bisect from the WebView team.

Not Hotlist-Interop since this is WebView-specific

 Issue 677634  has been merged into this issue.

battun@ could you bisect this using page in #1 and then assign back to queue.

Thanks!

Doesn't need bisect, I'm almost certain this is https://codereview.chromium.org/2380963002 "Use hide_scrollbars setting for Android WebView.".

WebView has always had a special quirk to hide all Blink-created overlay scrollbars; the Android native scrollbar is used instead on the root layer, to allow WebView developers to customize it on the Java side (which is the intended way to customize scrollbars), whereas sublayers didn't have scrollbars.  I wasn't aware that -webkit-scrollbar still worked and that some apps were using it instead.  WebView's disabling mechanism recently was refactored in 55 in a way that would also affect those.

-webkit-scrollbar harms scrolling performance and is a support burden, and will never be on any standardization track, so given that the change already made it to stable channel, I'm not sure we want to go out of our way to bring it back.  Developers can achieve the same behavior using JS/CSS (for sublayers) or using Java scrollbar customization (for the root layer).

How can developers achieve the same behavior using "JS/CSS" (besides this CSS)?  I have not been able to create always visible, customized scrollbars any other way.  For what it's worth I'm using Polymer, and this is the only way that I'm aware of.

You can place a small rectangle above the scroller ("position: fixed" if it's the root scroller), listen to JS onscroll events and reposition the rectangle accordingly.

That makes sense, but I'm sure you can see that creating a scrollbar from scratch, requiring JS, is far less convenient than a CSS-only solution, especially in the situation where there is no visible native UI (e.g. common Cordova implementation with a single WebView for entire UI).  Also, this inconsistency between WebView and Chrome makes me less interested in developing hybrid, WebView apps altogether, because I can't count on Chrome solutions working here.  I just hope this is taken into account as you consider whether or not to restore this functionality.

aelias@, it looks like -webkit-scrollbar is still supported by chromium in general (it doesn't appear to be in the intent to deprecate/remove process). If that's the case, it seems unfortunate for it to be removed from webview as a side effect of a change that wasn't intended to do that. Is it possible to undo this in a reasonable way?

If we were to deprecate and remove -webkit-scrollbar from blink, that'd be different; it wouldn't be surprising (or undesirable) that this also affects WebView.

Well, it's complicated.  This feature's usage is only somewhat above the threshold for deprecation (mostly kept afloat by desktop GMail), and this change just amplified a preexisting inconsistency between WebView and Chrome: WebView doesn't show non-customized sublayer scrollbars because of fear that they would be inconsistent with an Android-customized root scrollbar, and because it's always been that way.  WebView's scrollbar behavior is more internally consistent with this change made, even if it's diverged further from Chrome.

Anyway, the change cleanly reverts and the old method of scrollbar disabling wasn't that ugly, so I'll revert for now: https://codereview.chromium.org/2620743003 .  Until we can actually kick off deprecation, another reasonable path forward would be reading android:scrollbarThumbVertical resource so that Blink can render Android-custom scrollbar itself instead of crudely disabling them, although I'm not that's worth the engineering time to do.

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

commit 31baaeb8eb7991bc1a28fc93a6257ee23558cfcb
Author: aelias <aelias@chromium.org>
Date: Tue Jan 10 02:37:21 2017

Revert "Use hide_scrollbars setting for Android WebView."

This reverts commit 3d4d1a3324c680f6ef88deee59b25418c87be660.
This caused an unexpected regression in -webkit custom scrollbar
property support.

TBR=torne@chromium.org
BUG= 677348 ,  639806 

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

[modify] https://crrev.com/31baaeb8eb7991bc1a28fc93a6257ee23558cfcb/android_webview/native/aw_settings.cc
[modify] https://crrev.com/31baaeb8eb7991bc1a28fc93a6257ee23558cfcb/content/renderer/gpu/render_widget_compositor.cc

Thanks. I think this is fine until we can deprecate the feature entirely.

Revert will roll out in M57.

Fix verified on Galaxy Samsung S5 (SM-G900H)/MMB29K, LG G2(D802)/LRX22G, Acer Predator/LMY47I, Sony Xperia M2(Adreno 305)/18.6.A.0.182/5.1.1 & Galaxy Samsung S7 Edge(SM-G935A)/MMB29M with latest webview M57: 57.0.2984.0