MD Settings: Elim SettingsSubpageBrowsertest and SettingsPageVisibility

chrome/browser/resources/settings/settings_main/settings_main.js

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 /**
  * @typedef {{about: boolean, settings: boolean}}
  */
 var MainPageVisibility;
 
 /**
@@ skipping 53 matching lines @@
       value: false,
     },
 
     toolbarSpinnerActive: {
       type: Boolean,
       value: false,
       notify: true,
     },
 
     /**
-     * Dictionary defining page visibility.
-     * @type {!GuestModePageVisibility}
+     * Dictionary defining page visibility. Controlled by settings-ui.
+     * @type {!PageVisibility|undefined}
      */
-    pageVisibility: {
-      type: Object,
-      value: function() {
-        return {};
-      },
-    },
-
-    showAndroidApps: Boolean,
+    pageVisibility: Object,

[dpapad, 2017/05/01 21:02:22]

Can you run tryjobs? I am expecting that there might be some more fixes to be
made because some tests might fail. For example
https://cs.chromium.org/chromium/src/chrome/test/data/webui/settings/settings....

The previous code ensured that |pageVisibility| is initialized, even if you only
create a settings-main element (without a settings-ui parent), such that all
bindings are executing. The new code leaves pageVisibility undefined which might
affect those tests.

[stevenjb, 2017/05/01 23:42:58]

Ah, I thought I ran all tests locally, but it looks like CrSettingsMainPageTest
is disabled. 

Testing with --gtest_also_run_disabled_tests reveals that test is broken on ToT
and probably has been for a while. I don't see how loading settings-main without
settings-ui would work given all of our prefs dependencies.

I'll "fix" settings_main_test.js, but frankly I don't know whether fixing the
test is worth the effort.

[dpapad, 2017/05/01 23:56:34]

If the test is disabled, I don't think you have to fix it as part of this CL.
I've seen this pattern a few times now:

1) Test is flaky.
2) Sheriff disables flaky test.
3) Time passes, test remains disabled while code changes.
4) Someone starts looking into re-enabling the test, only to find out that the
test is no longer flaky, it fails consistently instead (the underlying flakiness
root cause might still be there though).

   },
 
   /** @override */
   attached: function() {
     this.listen(this, 'freeze-scroll', 'onFreezeScroll_');
     this.listen(this, 'lazy-loaded', 'onLazyLoaded_');
   },
 
   /** @private */
   onLazyLoaded_: function() {
@@ skipping 188 matching lines @@
               text: this.showNoResultsFound_ ?
                   loadTimeData.getString('searchNoResults') :
                   loadTimeData.getStringF('searchResults', query)
             });
           }
         }.bind(this));
       }.bind(this), 0);
     }.bind(this));
   },
 });