MD Settings: long dialog body should have overscroll line.

chrome/browser/resources/settings/passwords_and_forms_page/address_edit_dialog.js

Index: chrome/browser/resources/settings/passwords_and_forms_page/address_edit_dialog.js
diff --git a/chrome/browser/resources/settings/passwords_and_forms_page/address_edit_dialog.js b/chrome/browser/resources/settings/passwords_and_forms_page/address_edit_dialog.js
index 502d07a6a1911e58ef73c8c3c6b34b573e876101..f56ff5911293895ca425d33b64f27ea559fb1886 100644
--- a/chrome/browser/resources/settings/passwords_and_forms_page/address_edit_dialog.js
+++ b/chrome/browser/resources/settings/passwords_and_forms_page/address_edit_dialog.js
@@ -14,6 +14,7 @@ Polymer({
 
   behaviors: [
     I18nBehavior,
+    CrScrollableBehavior

[dpapad, 2017/02/18 00:37:17]

CrScrollableBehavior as advertized is meant to be used with iron-list (and has a
LOT of otherwise unnecessary code, for example this call to setInterval,
https://cs.chromium.org/chromium/src/ui/webui/resources/cr_elements/cr_scroll...).

AddressEditDialog is not using iron-list. Is there a better (and lighter) way to
achieve the desired overscroll behavior?

[scottchen, 2017/02/18 01:18:56]

I could copy just the scroll-class-attaching part of the javascript over, but
that's going to duplicate some good chunk of code.. thoughts?

[stevenjb, 2017/02/21 19:38:13]

I think that using CrScrollableBehavior here is fine. 

The referenced code is only called if updateScrollableContents() is called
explicitly. The code in ready() is necessary for the use case here, so there is
minimal extra overhead in including this behavior as-is.

We could update the behavior comment to say that it is designed to provide
paper-dialog-scrollable style borders for any scrollable container, with
additional helper methods to work around known issues with iron-list specific
behaviors.

   ],
 
   properties: {