Add options for audio/video autoplay to chrome://settings/content.

chrome/renderer/chrome_content_renderer_client.cc

Index: chrome/renderer/chrome_content_renderer_client.cc
diff --git a/chrome/renderer/chrome_content_renderer_client.cc b/chrome/renderer/chrome_content_renderer_client.cc
index 7910d84a9867a3b0e6b7b9220ddec95c07cb4469..40a7f8bbd5d25dd258f7042bf26b42dc59e44e1c 100644
--- a/chrome/renderer/chrome_content_renderer_client.cc
+++ b/chrome/renderer/chrome_content_renderer_client.cc
@@ -635,10 +635,15 @@ void ChromeContentRendererClient::DeferMediaLoad(
   // NOTE: This is also used to defer media loading for prerender.
   //
   // TODO(dalecurtis): Include an idle check too.  http://crbug.com/509135
-  if (render_frame->IsHidden() && !has_played_media_before) {
-    // Lifetime is tied to |render_frame| via content::RenderFrameObserver.
-    new MediaLoadDeferrer(render_frame, closure);
-    return;
+  const bool is_hidden = render_frame->IsHidden();
+  if (is_hidden && !has_played_media_before) {
+    ContentSettingsObserver* observer =
+        ContentSettingsObserver::Get(render_frame);
+    if (!observer->allowMediaAutoplay(is_hidden)) {

[philipj_slow, 2015/10/23 12:17:30]

What's happening here? On the face of things it seems possible to have autoplay
handling almost entirely within HTMLMediaElement, so that WebMediaPlayer then
simply does as it is told. Given that there's something called DeferMediaLoad I
can see that this already isn't the case.

liberato@, did you know about these bits, and is there any chance that the
autoplay experiment now thinks that we're trying to play in situations where
this code is actually deferring it further?

[DaleCurtis, 2015/10/23 19:21:27]

Chrome has long had a load deferral mechanism for prerender; I reused it to
avoid video playback during session restore and accidental background playback
in tabs the user has never seen before. There's no "open link in background tab"
on Android and Android session restore doesn't reload killed pages until they're
used for the first time AFAIK, so this shouldn't be an issue there.

[philipj_slow, 2015/10/28 10:30:40]

So is this entirely related to prerender and session restore, and has nothing to
do with implementing the preload policy for a media element in a "normal" active
document? If so should that actually change, shouldn't those loads continue to
be deferred? I think I still must be missing a piece of the puzzle :)

[DaleCurtis, 2015/10/30 19:25:56]

Ah, you're not missing anything, this does in fact break the session restore and
prerender cases :) At the very least prerender should continue to be blocked on
the visibility check regardless of the content setting. Session restore should
probably be separated out as well, but we'll vet with UX first. It would need
some new bit plumbed from the browser process too to indicate "process launched
for session restore."

+      // Lifetime is tied to |render_frame| via content::RenderFrameObserver.
+      new MediaLoadDeferrer(render_frame, closure);
+      return;
+    }
   }
 
   closure.Run();