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

chrome/renderer/content_settings_observer.cc

 // Copyright (c) 2012 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.
 
 #include "chrome/renderer/content_settings_observer.h"
 
 #include "base/command_line.h"
 #include "base/metrics/histogram.h"
 #include "components/content_settings/content/common/content_settings_messages.h"
 #include "content/public/common/url_constants.h"
@@ skipping 468 matching lines @@
     SendInsecureContentSignal(INSECURE_CONTENT_RUN_SWF);
 
   if (!allow_running_insecure_content_ && !allowed_per_settings) {
     DidBlockContentType(CONTENT_SETTINGS_TYPE_MIXEDSCRIPT, origin.host());
     return false;
   }
 
   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(
       routing_id(),
       blink::WebStringToGURL(frame->getSecurityOrigin().toString())));
 }
 
 void ContentSettingsObserver::didNotAllowPlugins() {
   DidBlockContentType(CONTENT_SETTINGS_TYPE_PLUGINS);
 }
@@ skipping 112 matching lines @@
 
   // If the scheme is file:, an empty file name indicates a directory listing,
   // which requires JavaScript to function properly.
   if (base::EqualsASCII(protocol, url::kFileScheme)) {
     return document_url.SchemeIs(url::kFileScheme) &&
            document_url.ExtractFileName().empty();
   }
 
   return false;
 }