MD Settings: Add Protected Content toggle to Site Settings

chrome/browser/resources/settings/privacy_page/privacy_page.html

Index: chrome/browser/resources/settings/privacy_page/privacy_page.html
diff --git a/chrome/browser/resources/settings/privacy_page/privacy_page.html b/chrome/browser/resources/settings/privacy_page/privacy_page.html
index e7ef19bd5a62d1c3c50c0d629e0eec8ef8e610b2..69799011f3eb11530ae012ce862ced95ef96a42e 100644
--- a/chrome/browser/resources/settings/privacy_page/privacy_page.html
+++ b/chrome/browser/resources/settings/privacy_page/privacy_page.html
@@ -437,6 +437,18 @@
           </site-data-details-subpage>
         </settings-subpage>
       </template>
+<if expr="chromeos or is_win">
+      <template is="dom-if" route-path="/content/protectedContent">
+        <settings-subpage page-title="$i18n{siteSettingsProtectedContent}">

[dpapad, 2017/02/03 22:03:14]

I think this blows up searching. Every subpage is expected to have an
associated-control attribute pointing to the element that opens the subpage, see
examples https://cs.chromium.org/search/?q=associated-control&type=cs.

The repro steps for seeing if this works would be to search for a term appearing
in the new subpage and see if the page is properly highlighted with a search
bubble.

[tommycli, 2017/02/03 22:09:15]

Done. I added a no-search attribute like the other subpages have. (Now I know
why they have that)

+          <div class="settings-box first">
+            <settings-toggle-button class="start"
+                pref="{{prefs.settings.privacy.drm_enabled}}"
+                label="$i18n{siteSettingsProtectedContentEnable}">
+            </settings-toggle-button>
+          </div>
+        </settings-subpage>
+      </template>
+</if>
     </settings-animated-pages>
   </template>
   <script src="privacy_page.js"></script>