Seeking designer input.

+finnur

Finnur and I talked about this originally. I believe this is the OS input and how default scroll would appear in any dialog across the OS, so would be more of a recommendation for Android to update if the trouble is with the scroll element itself.

I'm OK with shortening the dialog to make this clearer, but would that be hard to scale for all devices?

Alternatively - could we use the gradient fade element that appears at the bottom of the three-dot overflow menu and place it right above the line to help indicate more is below?

Here's a simple mock attached of it would look if we would make sure the list would always show 3.5 rows instead of full 4 rows.
Maybe 4.5 rows would be better... I'll let you be the judges there.

Deleted: mock.png 62.6 KB

	mock.png 62.6 KB View Download

I don't think there's an easy way to ensure that the dialog cuts the last item in half (the size would vary depending on the phone you are using). I think the right way to fix this is to make the scroll bar more obvious and I suspect that would be a global change (not sure where).

3.5 is fine. I know we run on very small devices so there is some mushy space as finnur@ says where this won't really fix things. But if you want to set a min for a larger device to help convey something below the fold you're welcome to push this out.

+tedchoc if he has a recommendation on who to contact on Android to ask about customizing the scrollbar (or what we can even do there.)

It seems straightforward to snap the height of the list to a half-multiple of 48dp (the height of an item_chooser_dialog_row: https://code.google.com/p/chromium/codesearch/#chromium/src/chrome/android/java/res/layout/item_chooser_dialog_row.xml) at https://code.google.com/p/chromium/codesearch/#chromium/src/chrome/android/java/src/org/chromium/chrome/browser/ItemChooserDialog.java&l=322-326.

We should probably also be using a 'waterfall' style (https://www.google.com/design/spec/components/toolbars.html) for the list as it scrolls, but I haven't looked into how to code that.

Android supports all types of customizations to scrollbars:
https://developer.android.com/reference/android/view/View.html#attr_android:fadeScrollbars
https://developer.android.com/reference/android/view/View.html#attr_android:scrollbarFadeDuration
https://developer.android.com/reference/android/view/View.html#attr_android:scrollbarDefaultDelayBeforeFade

While you can change the drawables used and all that, you definitely shouldn't in this case.  Deviating from the platform would be a mistake.

Why not put a shadow if you have additional things that can scroll?  We have a class that will do that for you (FadingEdgeScrollView).

And if you absolutely want to show X or X.5 views, you can do it, but it can be expensive.  Why would it be expensive you say?  Well, are your views wrap_content?  If so, the only way to do it is to query your adapter and get the first X views and call measure on them.  The scrollview/listview itself will also do that, but these values are not cached so you're doubling the effort.

Our views aren't wrap_content you say?  If you set an explicit height per row, then it is pretty easy since you can just multiple that height by your desired row count and set that.  [Sidebar: What happens if you make android use large font or on N where you can increase the zoom?  Wrap content views don't behave nicely in this mode and your text is often clipped]

But as Rebecca states, what happens if you're on a small phone in landscape and you can't fit X rows on the screen?  Well, then you need to ensure your height doesn't exceed your max available height (and of course you have to redo this calculation each time the orientation changes to make sure you're not making your dialog too large).

Soooooo...shadows are sounding pretty nice to me.  How about you all?

I'd love to see how users would respond to shadows!
Which one should we be using then?

(Thanks for the thoughts, tedchoc)

Shadows get into visual designer territory so I'd want to loop a VisD in. What would be most helpful is to see possible options. What kind of guidance would you need from UX for that? We don't use shadows much honestly, but I could look into specifications if that's needed.

We use shadows on the NTP and on the new payments UI to indicate additional scrollable content.  While we don't use shadows often, we use edge fades decently often.  Though they don't really work on white backgrounds, so we need to resort to the half cutoff stuff mentioned here.  I'd say we push to make shadows the more common language we use since it is much easier and I argue much clearer.

Ah I misinterpreted that (thought it meant shadows on the scrollbar itself.) I agree with a white fade out (mentioned in Comment 2 as well.) Glad there's an element for it.

fbeaufort@ - would you take this on or is there a PM to assign to for future prioritization?

https://codereview.chromium.org/2018213002/ has the simple change to make the list cut the last item in half.

FadingEdgeScrollView isn't obviously the right thing to use to make a list have shadows. First, it's a ScrollView whose documentation says "You should never use a ScrollView with a ListView". Second, it just draws shadows, without regard for material-design elevations. I probably won't get to shadows soon, but I'd be more comfortable if there were a class that clearly matched the material design guidelines.

Indeed, ListView has a built in ScrollView.  If you just make a copy of FadingEdgeScrollView and replace ScrollView with ListView, would it work in your case (I don't honestly know, but it "seems" like it should)?

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

commit af63104f71ad62bd89ba5c8bc61fde5c421fdd4c
Author: jyasskin <jyasskin@chromium.org>
Date: Tue May 31 23:12:48 2016

Set the Bluetooth chooser list height to cut through the middle of a list item.

This isn't the perfect fix, but it's easy and doesn't require us to
figure out how to draw shadows.

This also uses the DecorView's height instead of the WindowManager's Display's height in order to work well in multi-window mode.

BUG= 614300 , 603536 

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

[modify] https://crrev.com/af63104f71ad62bd89ba5c8bc61fde5c421fdd4c/chrome/android/java/src/org/chromium/chrome/browser/BluetoothChooserDialog.java
[modify] https://crrev.com/af63104f71ad62bd89ba5c8bc61fde5c421fdd4c/chrome/android/java/src/org/chromium/chrome/browser/ItemChooserDialog.java
[modify] https://crrev.com/af63104f71ad62bd89ba5c8bc61fde5c421fdd4c/chrome/android/java/src/org/chromium/chrome/browser/UsbChooserDialog.java
[modify] https://crrev.com/af63104f71ad62bd89ba5c8bc61fde5c421fdd4c/chrome/android/javatests/src/org/chromium/chrome/browser/ItemChooserDialogTest.java

Perfect. Here's attached a screenshot on Android N DP3 with latest chromium build including this fix.

Deleted: Screenshot_20160601-143415.png 104 KB

	Screenshot_20160601-143415.png 104 KB View Download

Looks good to me!

I've split the long-term fix with shadows into issue 617231. I think the half-height thing is enough to make the scrollbars more obvious.