MD Settings: show an extension-controlled-indicator for proxy

chrome/browser/resources/settings/system_page/system_page.js

Index: chrome/browser/resources/settings/system_page/system_page.js
diff --git a/chrome/browser/resources/settings/system_page/system_page.js b/chrome/browser/resources/settings/system_page/system_page.js
index 8656b29abab66238a917a17cd3e5a090711ce377..29d2f58a4a1b0e9f94924590f3fbfbcf1a612e61 100644
--- a/chrome/browser/resources/settings/system_page/system_page.js
+++ b/chrome/browser/resources/settings/system_page/system_page.js
@@ -33,6 +33,16 @@ Polymer({
   },
 
   /** @private */
+  onExtensionDisable_: function() {
+    // TODO(dbeam): this is a pretty huge bummer. It means there are things
+    // (inputs) that our prefs system is not observing. And that changes from
+    // other sources (i.e. disabling/enabling an extension from
+    // chrome://extensions or from the omnibox directly) will not update
+    // |this.prefs.proxy| directly (nor the UI). We should fix this eventually.
+    document.querySelector('settings-ui').getPrefsElement().refresh('proxy');

[dpapad, 2016/11/17 18:36:34]

With this selector system_page assumes that a settings-ui parent exists, and
makes a function call on it, which breaks encapsulation. For example, can you
still unit tests a <settings-system-page> as the only element in a page?

Alternative: Can we fire an event
this.fire('refresh-pref', 'proxy') and catch that event at a higher level, in
settings-ui itself? That makes the coupling between system-page and its parents
much looser (and keeps system-page test friendlier).

[Dan Beam, 2016/11/17 19:12:25]

that's a good idea

[Dan Beam, 2016/11/17 22:10:38]

Done.

+  },
+
+  /** @private */
   onRestartTap_: function() {
     // TODO(dbeam): we should prompt before restarting the browser.
     settings.LifetimeBrowserProxyImpl.getInstance().restart();