Add 'autoplay' content settings and expose it to Blink.

chrome/renderer/content_settings_observer.cc

Index: chrome/renderer/content_settings_observer.cc
diff --git a/chrome/renderer/content_settings_observer.cc b/chrome/renderer/content_settings_observer.cc
index cebc683a55be25c53110620f4ef7446a1070c7dc..661c941e7ef71b0cf18d67ee24167156855bfd35 100644
--- a/chrome/renderer/content_settings_observer.cc
+++ b/chrome/renderer/content_settings_observer.cc
@@ -486,6 +486,18 @@ bool ContentSettingsObserver::allowRunningInsecureContent(
   return true;
 }
 
+bool ContentSettingsObserver::allowAutoplay(bool default_value) {
+  if (!content_setting_rules_)
+    return default_value;
+
+  WebFrame* frame = render_frame()->GetWebFrame();
+  return GetContentSettingFromRules(
+             content_setting_rules_->autoplay_rules, frame,
+             blink::WebStringToGURL(
+                 frame->document().getSecurityOrigin().toString())) ==

[raymes, 2016/04/21 04:01:56]

Resolving content settings this way isn't great because it bypasses a lot of the
logic that lives in the browser. The code paths for figuring out what the actual
value is are different between browser/renderer (there are probably already
cases where it's wrong) and it means that if we implement new restrictions
around the setting in the browser, it won't get applied here. 

I know that it's hard to fix this because the value is needed synchronously (and
the existing code does this for other settings). Still, doing a sync IPC once
per navigation for all the values needed doesn't seem so bad if it means we
actually get correct values. We already have at least 3 sync IPCs in this file
for checking for access so we could potentially fold one (or more) of these IPCs
together and get all the info at once. For example, it looks like allowStorage
sends 2 sync IPCs already almost every navigation. So instead we could send 1
IPC and get the data for allowStorage as well as autoplay. This wouldn't
completely fix the existing problem for images/script because those may need to
check many origins per navigation...

[Bernhard Bauer, 2016/04/21 08:20:44]

Hm... it might be possible to make sure that the logic for doing these checks
renderer-side is the same as browser-side, if we do the separation between
content settings and permissions properly. If all the additional logic lives in
permissions, we could move it to common/ code, and abstract away the actual
mechanism that determines the raw content setting. Then in the browser the
content setting would be provided by HCSM, and in the renderer it would be
provided by GetContentSettingFromRules(). The logic inside of those would be the
same (HCSM just checks all the rules from all the providers in order).

+         CONTENT_SETTING_ALLOW;
+}
+
 void ContentSettingsObserver::didUseKeygen() {
   WebFrame* frame = render_frame()->GetWebFrame();
   Send(new ChromeViewHostMsg_DidUseKeygen(