MD Settings Fix associated-control for bluetooth, people, device subpage

chrome/browser/resources/settings/device_page/device_page.html

 <link rel="import" href="chrome://resources/html/i18n_behavior.html">
 <link rel="import" href="chrome://resources/html/md_select_css.html">
 <link rel="import" href="chrome://resources/html/polymer.html">
 <link rel="import" href="chrome://resources/html/web_ui_listener_behavior.html">
 <link rel="import" href="chrome://resources/polymer/v1_0/neon-animation/neon-animatable.html">
 <link rel="import" href="chrome://resources/polymer/v1_0/paper-icon-button/paper-icon-button-light.html">
 <link rel="import" href="device_page_browser_proxy.html">
 <link rel="import" href="display.html">
 <link rel="import" href="keyboard.html">
 <link rel="import" href="pointers.html">
@@ skipping 83 matching lines @@
           </settings-pointers>
         </settings-subpage>
       </template>
       <template is="dom-if" route-path="/keyboard-overlay">
         <settings-subpage
             associated-control="[[$$('#keyboardRow')]]"
             page-title="$i18n{keyboardTitle}">
           <settings-keyboard prefs="{{prefs}}"></settings-keyboard>
         </settings-subpage>
       </template>
-      <template is="dom-if" route-path="/stylus">
-        <settings-subpage
-            associated-control="[[$$('#stylusRow')]]"
-            page-title="$i18n{stylusTitle}">
-          <settings-stylus prefs="{{prefs}}"></settings-stylus>
-        </settings-subpage>
+      <template is="dom-if" if="[[hasStylus_]]">
+        <template is="dom-if" route-path="/stylus">

[jdufault, 2017/02/28 23:41:00]

Does navigating directly to the stylus subpage work correctly? Note that
hasStylus_ can go from false->true if the page load is happening from a Chrome
crash recovery.

[stevenjb, 2017/03/01 00:03:16]

Yes, the stylus page is fine. The problem is that checkPointerSubpage() will
navigate away from the subpage if hasMouse and hasTouchpad are false.

Arguably we may wish to modify that logic to also check hasStylus, in which case
we will need to set hasStylus ot be ininitialized also and just hide the stylus
section instead of using a dom-if, since bad things happen when dom-if
properties are undefined :(

[stevenjb, 2017/03/01 00:10:33]

I just realized I answered the wrong question :)

No, this does not work correctly. Investigating.

[stevenjb, 2017/03/01 00:31:37]

OK, I looked at this some more and understand why this is a problem. Basically
if we want to search the stylus page (which I would say we do, it has terms like
'Note-taking app'), and be able to navigate to the page directly, we need to
hide the section instead of dom-if it. I think that is reasonable here.

There is one quirk with searching hidden subpages - the search 'succeeds', but
nothing is highlighted. I think we can probably live with that? This is not
going to be the only such example I think.

+          <settings-subpage
+              associated-control="[[$$('#stylusRow')]]"
+              page-title="$i18n{stylusTitle}">
+            <settings-stylus prefs="{{prefs}}"></settings-stylus>
+          </settings-subpage>
+        </template>
       </template>
       <template is="dom-if" route-path="/display">
         <settings-subpage
             associated-control="[[$$('#displayRow')]]"
             page-title="$i18n{displayTitle}">
           <settings-display></settings-display>
         </settings-subpage>
       </template>
       <template is="dom-if" route-path="/storage">
         <settings-subpage
             associated-control="[[$$('#storageRow')]]"
             page-title="$i18n{storageTitle}">
           <settings-storage></settings-storage>
         </settings-subpage>
       </template>
     </settings-animated-pages>
   </template>
   <script src="device_page.js"></script>
 </dom-module>