Delete mediaPlaybackRequiresUserGesture

Delete mediaPlaybackRequiresUserGesture

The Android framework does not require a user gesture to begin media playback.
The web shouldn't have that restriction either.

BUG=178297
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=178731

[eseidel, 2014-07-22 19:24:39]

Can you help me understand this behavior?

Previously an <audio> element wouldn't start playing until a user clicked?  Or a
<video> couldn't auto play on page load?

Do we understand how this compares to other browsers?

I'm not objecting to this change, just seeking to understand what we're changing
here.

[eseidel, 2014-07-22 19:48:23]

It appears that iOS Safari has similar code, which appears to be enabled by
default:
http://trac.webkit.org/browser/trunk/Source/WebKit2/Shared/WebPreferencesStor...

Unclear w/o further testing.

This feels like an app vs. content split.  For content, particularly untrusted
content, a auto-play-blocking feature sounds useful.  Although I can tell you
from personal experience that it doesn't seem to work (at least on desktop)
since sometimes when I go to things like ibtimes.com the page starts talking to
me (today it seems to know how to self-mute for better or worse:
http://www.ibtimes.com/putin-says-he-will-use-influence-ukraine-rebels-denoun...
)

[abarth-chromium, 2014-07-22 19:51:20]

On 2014/07/22 at 19:48:23, eseidel wrote:
> It appears that iOS Safari has similar code, which appears to be enabled by
default:
>
http://trac.webkit.org/browser/trunk/Source/WebKit2/Shared/WebPreferencesStor...

I don't see why that's relevant.

> This feels like an app vs. content split.

The web serves both use cases.

[abarth-chromium, 2014-07-22 19:52:09]

On 2014/07/22 at 19:24:39, eseidel wrote:
> Can you help me understand this behavior?
> 
> Previously an <audio> element wouldn't start playing until a user clicked?  Or
a <video> couldn't auto play on page load?

Only on Android.  On other platforms we play the video when instructed to do so
by the web site.

[eseidel, 2014-07-22 20:08:41]

On 2014/07/22 19:51:20, abarth wrote:
> On 2014/07/22 at 19:48:23, eseidel wrote:
> > It appears that iOS Safari has similar code, which appears to be enabled by
> default:
> >
>
http://trac.webkit.org/browser/trunk/Source/WebKit2/Shared/WebPreferencesStor...
> 
> I don't see why that's relevant.

As you're well aware, we commonly consider other browsers' behaviors when
changing our own.
http://www.chromium.org/blink#new-features

> > This feels like an app vs. content split.
> 
> The web serves both use cases.

Correct.  Hence this configurability.

[eseidel, 2014-07-22 20:09:54]

On 2014/07/22 19:52:09, abarth wrote:
> On 2014/07/22 at 19:24:39, eseidel wrote:
> > Can you help me understand this behavior?
> > 
> > Previously an <audio> element wouldn't start playing until a user clicked? 
Or
> a <video> couldn't auto play on page load?
> 
> Only on Android.  On other platforms we play the video when instructed to do
so
> by the web site.

Correct.  This behavior is unique to Android as far as Blink is concerned.  It's
a hook to disable the 'autoplay' attribute, which it appears has made numerous
developers sad:
http://stackoverflow.com/questions/13266474/autoplay-audio-on-mobile-safari
http://stackoverflow.com/questions/4259928/how-can-i-autoplay-media-in-ios-4-...
http://stackoverflow.com/questions/8276202/autoplay-audio-with-ios-5-mobile-s...
http://makandracards.com/makandra/13893-autoplay-html5-audio-in-chrome-for-an...
https://github.com/mozilla/popcorn-js/issues/311

[esprehn, 2014-07-22 20:22:26]

On 2014/07/22 at 20:09:54, eseidel wrote:
> On 2014/07/22 19:52:09, abarth wrote:
> > On 2014/07/22 at 19:24:39, eseidel wrote:
> > > Can you help me understand this behavior?
> > > 
> > > Previously an <audio> element wouldn't start playing until a user clicked?
 Or
> > a <video> couldn't auto play on page load?
> > 
> > Only on Android.  On other platforms we play the video when instructed to do
so
> > by the web site.
> 
> Correct.  This behavior is unique to Android as far as Blink is concerned. 
It's a hook to disable the 'autoplay' attribute, which it appears has made
numerous developers sad:
> http://stackoverflow.com/questions/13266474/autoplay-audio-on-mobile-safari
>
http://stackoverflow.com/questions/4259928/how-can-i-autoplay-media-in-ios-4-...
>
http://stackoverflow.com/questions/8276202/autoplay-audio-with-ios-5-mobile-s...
>
http://makandracards.com/makandra/13893-autoplay-html5-audio-in-chrome-for-an...
> https://github.com/mozilla/popcorn-js/issues/311

The other side of this is
http://features.en.softonic.com/how-to-stop-video-auto-play-on-the-facebook-app
(there's a bunch of mentions of this issue for Facebook if you google around).
Even given the risk of video ads, I suspect we should expose the native platform
behavior. Otherwise we're just driving developers to build native apps.

[abarth-chromium, 2014-07-22 20:41:21]

On 2014/07/22 at 20:22:26, esprehn wrote:
> The other side of this is
http://features.en.softonic.com/how-to-stop-video-auto-play-on-the-facebook-app
(there's a bunch of mentions of this issue for Facebook if you google around).
Even given the risk of video ads, I suspect we should expose the native platform
behavior. Otherwise we're just driving developers to build native apps.

Precisely.

[philipj_slow, 2014-07-22 22:55:04]

Yes please, this fixes issue 178297. I investigated this a while back and wrote
a blog post and demo:
http://blog.foolip.org/2014/02/10/media-playback-restrictions-in-blink/
http://foolip.org/2014/02/10/media-playback-restrictions-in-blink/demo.html

As the demo shows, the restriction really amounts to "block playback until the
user touches the screen" which is just useless if developers work around it.

LGTM.

[philipj_slow, 2014-07-22 22:57:16]

https://codereview.chromium.org/414543002/diff/20001/Source/core/html/HTMLMed...
File Source/core/html/HTMLMediaElement.cpp (left):

https://codereview.chromium.org/414543002/diff/20001/Source/core/html/HTMLMed...
Source/core/html/HTMLMediaElement.cpp:351: if (document.settings() &&
document.settings()->mediaPlaybackRequiresUserGesture())
This was the last user of Settings, so the Settings.h include ought to be
superfluous.

[abarth-chromium, 2014-07-22 23:06:40]

On 2014/07/22 at 22:57:16, philipj wrote:
> This was the last user of Settings, so the Settings.h include ought to be
superfluous.

Done.

[abarth-chromium, 2014-07-22 23:06:45]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-07-22 23:08:17]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/abarth@chromium.org/414543002/40001

[commit-bot: I haz the power, 2014-07-23 00:47:33]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/16628)

[commit-bot: I haz the power, 2014-07-23 01:25:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-23 01:25:36]

Try jobs failed on following builders:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/16637)

[abarth-chromium, 2014-07-23 01:36:25]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-07-23 01:37:41]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/abarth@chromium.org/414543002/40001

[commit-bot: I haz the power, 2014-07-23 03:30:42]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/16647)
  win_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/win_gpu_triggered...)

[commit-bot: I haz the power, 2014-07-23 04:05:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-23 04:05:47]

Try jobs failed on following builders:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/16660)

[abarth-chromium, 2014-07-23 04:08:59]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-07-23 04:09:31]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/abarth@chromium.org/414543002/40001

[commit-bot: I haz the power, 2014-07-23 04:49:57]

Change committed as 178731

[qinmin, 2014-07-23 14:57:31]

On 2014/07/23 04:49:57, I haz the power (commit-bot) wrote:
> Change committed as 178731

Hi, Adam, your CL affects webview as setMediaPlaybackRequiresUserGesture() now
useless

[abarth-chromium, 2014-08-01 06:18:07]

A revert of this CL has been created in
https://codereview.chromium.org/428263004/ by abarth@chromium.org.

The reason for reverting is: We're going to gather some data about how users
react to autoplaying videos in order to decide whether to keep this restriction.