Chromium

Confirmed on Nexus 7 Device, on Chrome for Android Stable and Beta

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

I am able to duplicate this for Chrome 25 for Samsung Galaxy S3 running Android 4.1

According to the comment at https://code.google.com/p/chromium/issues/detail?id=138132#c6, the reasoning for this is to save data usage.  However, I have just been exploring how Chrome for Android handles setting the src of Audio objects and it seems to pull down the resource at the time src is set, but noops play for some reason.

The original reasoning for marking the previous issue "won't fix" seems to be somewhat invalid, as you can download terabytes of images without any user interaction.

Also, I believe this behavior is off-spec.

This is a huge hinderance for HTML5 gaming.

Another place to test correct behavior is Firefox for Android.

We operate an online learning web site, and due to this issue we are recommending that our customers use a different browser if they have an Android device.  Many of our users are children, and having sounds automatically play helps keep them focused and engaged.  Of course, we could add an on-screen "play" button specifically for Android Chrome users, but this adds unnecessary screen clutter and creates extra development overhead.

It's only fair to point out that Apple had the same issue with Safari on iOS 5, and they removed this limitation in iOS 6.  I'm sure they had a good reason.

If data usage is a concern, why not try an approach that is more user-friendly?  You could:

- Make this a setting.
- Display a warning when a user first visits a web page with an audio element, then provide an option to either enable or disable automatic audio playback.
- Automatically play audio under Wi-Fi, but not under a cellular connection.
- A combination of the above.

So is anything here is moving forward? Or just left as unimportant issue?

Building abstractions on top of the audio api is made needlessly complex by this - I understand that you do not want audio to be triggerable arbitrarily by scripts, which makes sense, but there has to be a better way.

I imagine it's probably a pretty easy change from a code perspective, if you know where to look. Maybe the next step is to make the patch, and then we can discuss the pros and cons as we seek to land it?

Anyone familiar enough with the code to know where this happens?

This is implemented using a behavior restrictions system in HTMLMediaElement, and is controlled by a setting controlled by the embedder, i.e. Chromium. Relevant snipped from the HTMLMediaElement constructor:

    if (document.settings()) {
        if (document.settings()->mediaPlaybackRequiresUserGesture()) {
            addBehaviorRestriction(RequireUserGestureForRateChangeRestriction);
            addBehaviorRestriction(RequireUserGestureForLoadRestriction);
        }
        if (document.settings()->mediaFullscreenRequiresUserGesture()) {
            addBehaviorRestriction(RequireUserGestureForFullscreenRestriction);
        }
    }

On Android, the outermost layer that sets this preference is in content/browser/renderer_host/render_view_host_impl.cc:

#if defined(OS_ANDROID)
  prefs.user_gesture_required_for_media_playback = !command_line.HasSwitch(
      switches::kDisableGestureRequirementForMediaPlayback);
  prefs.user_gesture_required_for_media_fullscreen = !command_line.HasSwitch(
      switches::kDisableGestureRequirementForMediaFullscreen);
#endif

In other words, the code change would be a one-liner, the hard part is deciding whether or not to do it. In Opera for Android we've added an ongoing notification when media is playing, and I think that with this is much less of a problem with sites auto-playing media, since it's always easy to stop them again.

That being said, I don't feel strongly about this.

[Empty comment from Monorail migration]

@philip, thank you!

I agree the big question is making the policy decision. Unfortunately I don't know how Chrome development works enough to know how best to go about getting the decision made. I do believe it's in the best interest of both web developers and web users that we move past the current state, though.

The notification solution seems ideal... that keeps the user in control, but doesn't pester them needlessly. How would we go about adding that in?

First of all, my personal opinion is that we should honor play() requests. Ideally we should just set the user_gesture_required_for_media_playback flag to false for Android.

A dialog could be an option, and if so it could be implemented in a similar way as the full screen API dialog (i.e. add an interface in the content API for the browser to implement). But before doing that, let's consider this scenario:

When a Web developer wishes to trigger audio playback without user interaction (e.g. in a game or a demo), she finds that the Audio element does not work on Android. Instead she finds that the Web Audio API does allow non-user-initiated playback, and so goes ahead and explicitly pre-loads all audio assets on page load (because that's the way Web Audio works), instead of streaming them on demand.

So, if we're serious about blocking automatic audio streaming on Android, we should probably also consider having similar mechanisms for Web Audio - and right about here things start to get absurd IMO.

We definitely don't want a dialog... it's that kind of annoying user interruption we're trying to avoid. I do like the idea of a quiet notification that just sits in the notification panel. You don't have to interact with it, but if you want to, you can pull it down and use it to pause the music, just like in Android Opera.

That said, maybe the first step is to just disable user_gesture_required_for_media_playback for starters, and then add the notification in a future release.

Another scenario is an instant messaging application, where a short alert sound is played upon receiving a new message. It's possible in Safari in iOS, and it should be possible in Chrome for Android.

I've just discovered another situation where this is causing trouble: getUserMedia in combination with a <video> element.

For instance, http://shinydemos.com/clock will only show a still image instead of a moving video unless you disable the user gesture check. The problem in this case is that video.play() does nothing (as it is blocked by mediaPlaybackRequiresUserGesture) :-(

I've found a workaround that makes the restrictions rather pointless as currently implemented:

http://blog.foolip.org/2014/02/10/media-playback-restrictions-in-blink/

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

My issue just got merged in to this one, so I'll add the tl;dr:

The workaround is to AJAX the whole file and play it with the Web Audio API. Then you can play outside of a user input event. Contrary to the rationale that "it will cost data usage", this method actually could use more data than if play() worked: the entire track must be downloaded before it can start playing, compared to <audio> which can stream as it plays. And the Web Audio API decompresses the entire track in one go, which can take 10sec+ by itself and uses lots of memory, which sucks for low-memory devices.

So this limitation is nothing but a hindrance to legitimate use cases, I cannot imagine why it hasn't been changed already.

[Empty comment from Monorail migration]

[Comment Deleted]

per #6, would you please provide a sample webpage that autoplay works on ios 6/7 ?

I tried the link in #1 and http://www.w3schools.com/tags/att_audio_autoplay.asp, and none of them works.

[Empty comment from Monorail migration]

Just to summarize what I wrote in my blog post, the current model is really "disallow playback until the user has touched, clicked or pressed a key anywhere in the document", but it's by accident so the "API" for a Web developer to work with this model is peculiar, to say the least.

We've removed the restrictions entirely in Opera beta for Android. The only other sane option I can see is to fix the model so that only a play() which later causes media to actually play lifts the restrictions, possibly on a page-wide level, but that's still going to break playlists in iframes and whatnot.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

If keeping this restriction, can it at least not fail silently? When using remote debugging, there is not even an error or warning in the console to indicate that the audio isn't going to play.

Failing these restrictions originally did throw exceptions, but I don't think going back to that's an option, it would break any script that fails to catch the exception. Something in the error console would be OK, though.

I think that if we want to keep these restrictions, we really should standardize the (optional) behavior, so that people don't have to reverse engineer to figure out how it works.

[Comment Deleted]

yes

I got it. Thank you !

Chrome for Android: You can disable the 'gesture required' flag by going to 'about:flags' in your chrome. Then find the flag 'disable gesture requirement for media playback' and click 'enable', at the bottom of the page box will appear that says 'Your changes will take effect the next time you relaunch Google Chrome' and a button 'Relaunch Now'. Click the button. You can now start videos via javascript.

For some reason this seems to be the best kept secret on the Internet. I searched for months before finding this. Good luck.

I understand, but it is a start. I find this issue particularly annoying on tablets that only have wifi connectivity. I kinda understand the rationale on phones where one is (unjustifiably) charged for connect time but not on tablets that are wifi connected. It seems to me that Chrome could check to see if the connection is via wifi and then allow autoplay.

@octobclr - the workaround is to play sound effects with the Web Audio API. However it's unsuitable for music, since it must fully download and decode the whole file before it can play.

Seems like if someone wanted to make a patch to remove this restriction entirely, the "gesture required" flag code might be a good starting point. I think making a patch would be a good way to move this conversation to the next level.

We have a chat app that needs to make a clicking sound when a new message arrives. Please make auto-play of <audio> tag possible!

One solution for this and many other situations like this is making an api that can request the user to change a flag in a simple way, something like the Remember password bar.
"xyz.com needs X feature Approve*     Deny (*May cause Y problems)"

From a pseudo-geek that builds solutions for people who are deaf or blind....
I appreciate all the effort you guys are making to fix this annoying problem.  What Apple, Google, et al have failed to realize, is making a requirement to click a link that many people can NOT see.  I also have a need to autoplay an mp3 in various venues, for reasons that don't only include entertainment.  The work-arounds (VoiceOver and TalkBack) are inadequate, at best, and create other problems.  
For what it's worth, my thought is to create a switch under Accessibility options to enable autoplay.

There's a review up for this now: https://codereview.chromium.org/414543002/

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

One thing to keep in mind is potential security and privacy exploits (see http://arxiv.org/pdf/1407.4923.pdf for one such example).

As mentioned previously the Web Audio API can already play without user gesture so this does not add any security/privacy issues that are not already possible with that. It serves only to hinder legitimate use cases e.g. playing music in games.

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=178731

------------------------------------------------------------------
r178731 | abarth@chromium.org | 2014-07-23T04:49:52.868403Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLMediaElement.cpp?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-canvas-expected.txt?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-play-require-user-gesture.html?r1=178731&r2=178730&pathrev=178731
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebSettingsImpl.cpp?r1=178731&r2=178730&pathrev=178731
   M http://src.chromium.org/viewvc/blink/trunk/public/web/WebSettings.h?r1=178731&r2=178730&pathrev=178731
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLMediaElement.h?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-canvas.html?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-preview-expected.txt?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/no-autoplay-with-user-gesture-requirement-expected.txt?r1=178731&r2=178730&pathrev=178731
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebSettingsImpl.h?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-play-require-user-gesture-expected.txt?r1=178731&r2=178730&pathrev=178731
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/frame/Settings.in?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-preview.html?r1=178731&r2=178730&pathrev=178731
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/FlakyTests?r1=178731&r2=178730&pathrev=178731
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/no-autoplay-with-user-gesture-requirement.html?r1=178731&r2=178730&pathrev=178731

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

Review URL: https://codereview.chromium.org/414543002
-----------------------------------------------------------------

The fix affects android webview as setMediaPlaybackRequiresUserGesture API now useless.

[Empty comment from Monorail migration]

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=179369

------------------------------------------------------------------
r179369 | abarth@chromium.org | 2014-08-01T06:19:42.893742Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-play-require-user-gesture.html?r1=179369&r2=179368&pathrev=179369
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebSettingsImpl.cpp?r1=179369&r2=179368&pathrev=179369
   M http://src.chromium.org/viewvc/blink/trunk/public/web/WebSettings.h?r1=179369&r2=179368&pathrev=179369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLMediaElement.h?r1=179369&r2=179368&pathrev=179369
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-canvas.html?r1=179369&r2=179368&pathrev=179369
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-preview-expected.txt?r1=179369&r2=179368&pathrev=179369
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/no-autoplay-with-user-gesture-requirement-expected.txt?r1=179369&r2=179368&pathrev=179369
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebSettingsImpl.h?r1=179369&r2=179368&pathrev=179369
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-play-require-user-gesture-expected.txt?r1=179369&r2=179368&pathrev=179369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/frame/Settings.in?r1=179369&r2=179368&pathrev=179369
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-preview.html?r1=179369&r2=179368&pathrev=179369
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/FlakyTests?r1=179369&r2=179368&pathrev=179369
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/no-autoplay-with-user-gesture-requirement.html?r1=179369&r2=179368&pathrev=179369
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLMediaElement.cpp?r1=179369&r2=179368&pathrev=179369
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/media/video-capture-canvas-expected.txt?r1=179369&r2=179368&pathrev=179369

Revert of Delete mediaPlaybackRequiresUserGesture (https://codereview.chromium.org/414543002/)

Reason for revert:
We're going to gather some data about how users react to autoplaying videos in order to decide whether to keep this restriction

Original issue's description:

TBR=eseidel@chromium.org,philipj@opera.com
NOTREECHECKS=true
NOTRY=true
BUG=178297

Review URL: https://codereview.chromium.org/428263004
-----------------------------------------------------------------

Hopefully something can be learned from that data that would help improve the implementation if it can't simply be removed...

New CL: https://codereview.chromium.org/447353002

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/813baab3c7bace491664e670ad4c54aff0718b95

commit 813baab3c7bace491664e670ad4c54aff0718b95
Author: abarth@chromium.org <abarth@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Fri Aug 08 10:25:49 2014

Enable HTMLMediaElement@autoplay on Android

This CL sets user_gesture_required_for_media_playback to false in Chrome for
Android. Previously, we removed this requirement as a special case for the
Google Search Results page. Now that this setting matches Chrome's behavior on
other platforms, we don't need the special case for google.com and can remove
the entire VoiceSearchTabHelper.

This CL leaves the user_gesture_required_for_media_playback WebPreference
because that's used by android_webview.

R=klobag@chromium.org, darin@chromium.org
BUG=178297

Review URL: https://codereview.chromium.org/447353002

Cr-Commit-Position: refs/heads/master@{#288308}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@288308 0039d316-1c4b-4281-b951-d872f2087c98

------------------------------------------------------------------
r288308 | abarth@chromium.org | 2014-08-08T10:25:49.994432Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_process_host_impl.cc?r1=288308&r2=288307&pathrev=288308
   D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/android/java/src/org/chromium/chrome/browser/VoiceSearchTabHelper.java?r1=288308&r2=288307&pathrev=288308
   D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/android/voice_search_tab_helper.cc?r1=288308&r2=288307&pathrev=288308
   D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/android/voice_search_tab_helper.h?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/common/content_switches.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/common/content_switches.h?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/shell/app/shell_main_delegate.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/media/encrypted_media_browsertest.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/media/encrypted_media_browsertest.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/media/media_source_browsertest.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/common/web_preferences.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/android/chrome_jni_registrar.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/android/java/src/org/chromium/chrome/browser/Tab.java?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/about_flags.cc?r1=288308&r2=288307&pathrev=288308
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_view_host_impl.cc?r1=288308&r2=288307&pathrev=288308

Enable HTMLMediaElement@autoplay on Android

This CL sets user_gesture_required_for_media_playback to false in Chrome for
Android. Previously, we removed this requirement as a special case for the
Google Search Results page. Now that this setting matches Chrome's behavior on
other platforms, we don't need the special case for google.com and can remove
the entire VoiceSearchTabHelper.

This CL leaves the user_gesture_required_for_media_playback WebPreference
because that's used by android_webview.

R=klobag@chromium.org, darin@chromium.org
BUG=178297

Review URL: https://codereview.chromium.org/447353002
-----------------------------------------------------------------

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2289b43cabb4b6e5790170045da2cb9bb92eb783

commit 2289b43cabb4b6e5790170045da2cb9bb92eb783
Author: abarth@chromium.org <abarth@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Fri Aug 08 17:52:11 2014

Revert of Enable HTMLMediaElement@autoplay on Android (https://codereview.chromium.org/447353002/)

Reason for revert:
I misunderstood the outcome of the discussion surrounding this topic. We need to keep this code in order to not break google.com while gathering data about this feature.

Original issue's description:

TBR=darin@chromium.org,klobag@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=178297

Review URL: https://codereview.chromium.org/453023002

Cr-Commit-Position: refs/heads/master@{#288389}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@288389 0039d316-1c4b-4281-b951-d872f2087c98

------------------------------------------------------------------
r288389 | abarth@chromium.org | 2014-08-08T17:52:11.815043Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/media/encrypted_media_browsertest.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/media/encrypted_media_browsertest.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/media/media_source_browsertest.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/common/web_preferences.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/android/chrome_jni_registrar.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/android/java/src/org/chromium/chrome/browser/Tab.java?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/about_flags.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_view_host_impl.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_process_host_impl.cc?r1=288389&r2=288388&pathrev=288389
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/android/java/src/org/chromium/chrome/browser/VoiceSearchTabHelper.java?r1=288389&r2=288388&pathrev=288389
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/android/voice_search_tab_helper.cc?r1=288389&r2=288388&pathrev=288389
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/android/voice_search_tab_helper.h?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/common/content_switches.cc?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/public/common/content_switches.h?r1=288389&r2=288388&pathrev=288389
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/shell/app/shell_main_delegate.cc?r1=288389&r2=288388&pathrev=288389

Revert of Enable HTMLMediaElement@autoplay on Android (https://codereview.chromium.org/447353002/)

Reason for revert:
I misunderstood the outcome of the discussion surrounding this topic. We need to keep this code in order to not break google.com while gathering data about this feature.

Original issue's description:

TBR=darin@chromium.org,klobag@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=178297

Review URL: https://codereview.chromium.org/453023002
-----------------------------------------------------------------

[Empty comment from Monorail migration]

It feels as though this type of issue is well known territory. When a site (Google.com or a lesser known one) wants to access location, the webcam, and so on, a one-time permission notification is shown. The user grants or denies the permission, and the resulting functionality is as close as possible to what the user wants.

I don't feel that a Google.com exception is appropriate. Is there a precedent for Google-specific properties being exempt from feature crippling in Chrome, or is this the first instance of it? It's Google's browser, but this feels as though it is not keeping with Google or Chrome's principles as they have been stated in the past.

Does google.com depend on the restriction being in place, so that it breaks with no restrictions? That sounds pretty odd...

> Does google.com depend on the restriction being in place, so that it breaks with no restrictions? That sounds pretty odd...

We're going to run an A/B experiment with autoplay enabled and disabled.  In the "autoplay disabled" branch of the experiment, we need that code in order to not break google.com, which relies upon autoplay working.

I see, there was already an exemption for google.com, so it wasn't depending on the default behavior but rather the exemption.

BTW, it should be possible to fix google.com to work around the restriction by priming audio elements on any user input, which presumably has to occur anyway before there's any sound to play.

I am all for a permission dialog and have previously brought it up with the W3C for inclusion in the spec (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25554). I realize games need to auto-play music, but there are also plenty of people with low data caps who can't afford media elements pre-loading data in the background. A one-time permission request seems like the most reasonable solution for everyone.

The "Images can already consume data in the background, so why bother?" argument (#5) doesn't seem valid to me, because one doesn't usually expect many, many high-definition images to be loaded during casual web browsing. High definition video, however, is now commonplace on the web.

I would hope that the permission dialog feature would also be applied to the desktop version of Chrome (even if its behind a runtime flag) for those of us who are forced to use heavily-capped satellite or cellular home internet services.

Audio files are tiny (~1MB/min) compared to high definition video, so I don't find the low data cap argument convincing for audio. Having said that, I agree that a one-time permission per website, remembered by the browser (much like flash deals with device permissions), would be reasonable.

> The "Images can already consume data in the background, so why bother?" argument (#5) doesn't seem valid to me, because one doesn't usually expect many, many high-definition images to be loaded during casual web browsing.

HTML5 games typically do this. They may involve a large download which is 90% images and 10% sound effects. The images can auto-download and display without interaction, but the sounds can't play without interaction.

If there is a permission dialog then will it ask for permission to download those images, even though they took 9x as much bandwidth? What about background AJAX requests to download large resources like meshes for WebGL games? Why has media been singled out here?

> I don't find the low data cap argument convincing for audio.

You're right. I was mostly referring to video.

> What about background AJAX requests to download large resources like meshes for WebGL games? Why has media been singled out here?

Obviously when one intends to play an HTML5 game, they can expect large amounts of data to be downloaded. I'm talking about casual web browsing on websites that unexpectedly pre-load HTML5 media for video/audio players.

Just heard today from another client that needs auto play of mp3. Her
dyslexia requires it for certain non-gaming applications.  Users who are
blind cannot be expected to find and activate an audio file. The one-time
permission should be an Accessibility option, not presented when loading
the first web page offering the audio. That strategy still insults the
blind.
Think inclusion.

I'm porting a game like app to the web with emscripten. It relies on using videos as texture animations. The game logic decides when to start a texture animation. Works great with desktop chrome but I don't seen any way to make it work in chrome on android.

If it's not possible to to allow all websites to play videos without user interaction may be it could be allowed for webapps added to the start screen. They can already request special treatment like being run fullscreen because there is already user interaction involved in "installing" them.

This is an incredibly strange limitation to impose, given the Media Source Extensions spec and the Chromium developers' eagerness to implement it.  With this API I can download an entire video via XMLHttpRequest and have it ready, but am unable to play it until the user performs a gesture on their device.

Furthermore, this limitation hasn't really stopped those most determined from autoplaying videos.  I work for an online ad company and have recently been tasked with animating videos in a canvas element instead of a video element, purely because one of our competitors has done this and our customers are demanding it.  Rather than preventing us from autoplaying videos, the Chromium and Safari developers have instead forced us to choose a less efficient video encoding method and actually increased the amount of data downloaded by users, as well as increased power usage from having JavaScript decode video frames instead of the native video decoders.

darin, klobag, felt: Where should we be on this?

I'm completely astounded - I fought for weeks debugging this - ripping and refactoring my app just to find the problem - only to find out that it's an intentional violation of the spec as it's written.

Despite the fact that it's bad practice and very Microsoft-y of you to by-pass agreed upon specs - why in the world won't you at least give developers some warning in the console or something???

We are investigating the impact of autoplay in https://code.google.com/p/chromium/issues/detail?id=402044.

At the same time, Firefox is considering to require user gesture even autoplay is true for video.

[Empty comment from Monorail migration]

It's things like this that make me miss programming in COBOL.

I doubt A/B testing will produce meaningful conclusions. You'd be controlling the very variable that you should be observing, which is whether or not end-users want autoplay on or off. And imo, even with valid results, the only thing a study like this should inform is what the default is to be for a user-configurable setting.

More generally, I think it's a bad idea to patronize one's users. Something is obviously wrong when the outcome of a policy is exactly the opposite of its supposed intent. Yet this is the predictable result of an approach that presumes people incapable of acting in their own (and their own customers') best interests.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Wouldn't it make sense to extend the bug to include HTML video too? It's basically the same thing, isn't it?

Yes, the restrictions are exactly the same for audio and video.

By the way, a workaround for audio is to use the WebAudio API instead.

Yes, WebAudio can work for small clips of a few seconds. For large music clips (1+ minutes), the decoding typically takes too long, especially on ARM phones and tablets.

Or, you can set the --disable-gesture-requirement-for-media-playback Chromium flag.

In Cordova Crosswalk, you can enable this flag by adding "xwalk --disable-gesture-requirement-for-media-playback" inside a "/platforms/android/assets/xwalk-command-line" file.

Note that due to this restriction, gamepad-controlled HTML5 games can never play audio or video, because the user never provides the required touch event. I filed this as a separate https://crbug.com/chromium/454849.

Can you use gamepad-control to set focus, e.g. inputbox or click a link?

We should recognize it as user gesture. If not, it is a bug we can fix.

I don't know - for the use case of HTML5 games, it's irrelevant, since games generally do not make use of anything focusable (canvas only).

I agree this is a bug that should be fixed. If the user starts interacting with the gamepad on a given page than it's probably ok to allow that page to start audio. It is far from trivial what would be an appropriate behavior considering both UX and security though.

[Empty comment from Monorail migration]

Recognizing gamepad actions as user gestures is not sufficient for in-game sounds which are not triggered by the user's character.

Per the original report, something that would make this a lot better would be keeping track of event chains having started with a user gesture. That would enable one sound to play after another, at least.

Alternatively, allowing DataURL sounds to play would remove the hindrance for many webapps & games, but without additional data usage.

[Empty comment from Monorail migration]

This is unbelievable. Whoever took the design decision to implement this limitation was a RETARDED.

First of all, there's no reason this should be applied when connected via wifi, it only makes sense when connected via mobile data.

Secondly, the "only if started by user action" paradigm is STUPID. It doesn't fulfil the purpose of protecting the user from playing unwanted audio in the first place, and the limitations are unacceptable, because it would require a user interaction for EVERY single adio that needs to be played (I have verified: even if the user triggers an audio by a click, any other subsequent audio that needs to play automatically cannot).

How is it possible that you don't see the OBVIOUS and only correct way to do this, if you really want to protect the user from undesired streaming of media??
Just issue a popup prompt the first time a page wants to play some media without user interaction. Ask for user confirmation and give the user the option to check "don't show this message again" (or "allow future media streamings from this page" or whatever). That's the ONLY acceptable way of limiting playing media, if it has to be limited at all.

This is ridiculous, never seen anything this stupid.

It lowest-common-denominator thinking. I guess it was designed to protect against overage charges, or something like that. However, you can use the WebAudio API for small clips, as a workaround.

It's basically as simple as a switch in the browser engine. I wouldn't expect this to change for another few years ... unless HTML5 games become more mainstream, or a major competitor (i.e.: Apple) changed it also.

- Comparing to exactly described key words in RFCs (MUST, MUST NOT...), W3 drafts are a mess: "User agents do not need to support autoplay, and it is suggested that user agents honor user preferences on the matter." vs "The autoplay attribute is a boolean attribute. When present, the user agent (as described in the algorithm described herein) will automatically begin playback of the media resource as soon as it can do so without stopping." Where exactly can developers read about browser and platform specific behaviors (like this bug report)?
-> If web designer first encounter this, why don't you at least put some notice in console log (even IE learned that)?

- Is the restriction in place to avoid surprising users with immediate audio playback?
-> If yes, why isn't it also in Chrome on desktop?

- Is the restriction in place to avoid excessive data usage?
-> Why the restriction apply on 10 inch Android tablet with Wifi but not laptop (or Chromebook) also running Chrome and connected to the same Wifi?

- HTML5 Audio supports loop but it's not gapless so it's not good enough for various cases. Web Audio API fixes at least that.
-> But this restriction doesn't apply to Web Audio API. Why not? It should be consistent.

- Web Audio API isn't general solution because it's not enough to autoplay in Safari on iOS.
-> Because of this, designers have to come with a solution for starting playback from click/tap context. Say I want to design site such as Youtube which plays video after clicking from list of results (it indeed works).

But why are you making it so hard? It's year 2015 and you still force designers to check for user agent and optimize sites for multiple UAs simply because there's no property telling whatever autoplay is supported.
Today it's still possible to create desired behavior (at least for most cases) but it wastes so much time of many talented web designers all around the world.

[Empty comment from Monorail migration]

#99: this functionality is already possible on iOS, albeit with a little doing. On the first touch event, you can call a .play() method and have it take, and _all_ subsequent ,play()'s will work. On Android Chrome, there is a 1-touch-1-play requirement for <audio> . This, in combination with https://crbug.com/chromium/424174, make Android Chrome almost unusable for any kind of multimedia experience at the moment.

#102,  there is non 1-touch-1-play requirement for <audio>.

If a user gesture is involved in calling play() or load(), the media element no longer requires any user gesture for subsequent play() calls.

#103, can you elaborate? What you are saying seems to contradict https://crbug.com/chromium/350645.

Are the Android limitations on this documented anywhere other than this issue and the chromium code?

More broadly, it seems as though Chrome has a whole bunch of (afaik) undocumented limitations and quirks. I know it's broader than this specific issue, but I would like to urge the Chrome team to please start documenting this stuff.

in crbug/350645, you are creating a new audio element after the first ended.
Since user gesture is waived for the 1st audio element, but not the 2nd element., so the 2nd element won't automatically play.
Here is an example that the 2nd video will autoplay after the first one finishes by changing src attribute: http://videotestsuite.appspot.com/test?test=swap-ended

Android chrome's autoplay behavior is similar to that of ios safari. So if  a workaround works on android, it will also work on ios.

Changing the src attribute on the same element seems to only work for video.

Video (working on desktop & android):
https://jsfiddle.net/es339cht/1/

Audio (working on desktop, not working on android):
https://jsfiddle.net/es339cht/2/

Do you have an example that works with audio?

#106, it looks like an issue with your audio file. The ended event is never fired, possibly some format issue with the mp3 file.

I tried http://www.w3schools.com/htmL/horse.mp3, and the ended event is fired.

#103: thank you for the clarification. In order to support multiple overlaid audio effects our engine now creates 100 Audio elements with an "empty" WAV data URIs, calls play() on all of them on first touch, then changes the src's of this pool to blob URL's to cue in-game audio.

As a data point: this is  an extremely cumbersome workaround, especially when Web Audio does not carry with it these restrictions, but instead a severe performance penalty.

#108, you can actually call play() on a media element with no src at all to prime it for later use. It's still very frustrating, but at least the browser won't have to decode a bunch of empty audio files.

#109: That's excellent, thank you so much for the lead on this.

#107, thank you for pointing that out. I have filed https://crbug.com/chromium/482788 for the non-firing ended events, since the event does fire in desktop Chrome.

Hi, I want to play audio right after my game is loaded. Here is a little demo (see the source code) http://www.ivank.net/veci/sound .
It works in Firefox for Android, but not in Chrome for Android.

I can play audio right after page is loaded in Chrome for Android using Web Audio API. But it requires decompressing the whole audio file into raw data, my 20min will take 400 MB of RAM.

Isn't it just stupid to restrict HTML5 Audio, but not Web Audio API?

Dudes, please just fix this. I just wasted 2 hours of lifetime searching for a bug in my code. Even fracking Internet Explorer works, this is unbelievable...

Many greets from Germany,
Peter

I/chromium(11922): [INFO:CONSOLE(0)] "Failed to execute 'play' on 'HTMLMediaElement': API can only be initiated by a user gesture."

I'm getting this error from my new HTML5 web app for the blind running on Google Chrome on Android 5.01 (HTC One M8) when trying to play sounds that are automatically generated from live camera frames. Requiring a user gesture is not acceptable here (or at most once at program start, but certainly not every few seconds). Why does this restrictive API invocation policy exist? Enabling the "Disable gesture requirement for media playback" in chrome://flags is a workaround that fixes the problem, but is too much hassle for the average (blind) user of my web app. Moreover, the "save data" argument does not apply at all in my case, because I am playing a URI resource that is being generated on-the-fly in memory, with zero external communication.

BTW, Firefox on Android does not give this problem and works as intended (by me) out-of-the-box.

Thanks

[Empty comment from Monorail migration]

[Comment Deleted]

Adding Restrict-AddIssueComment-EditIssue since we seem to be getting comments that use derogatory language.

If you are interested in seeing this bug fixed, please Star it.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Renaming Blink>Audio to Blink>Media>Audio for better characterization

[Monorail components: -Blink>Audio Blink>Media>Audio]

Renaming Blink>Video to Blink>Media>Video for better characterization

[Monorail components: -Blink>Video Blink>Media>Video]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Monorail components: -Security>UX Internals>Permissions>Model]

[Empty comment from Monorail migration]

[Monorail components: -Security>UX Internals>Permissions>Model]

+ojan and +kenji who think about how we handle these kind of interventions generally.

Predictability program has set an OKR to gain traction on the top 50 starred bugs this quarter: either by closing them, stating what milestone the fix will ship, or setting a NextAction date so that we know when to check back in.

@Ojan, Kenji, Mounir - do we have consensus on what our answer is for this bug? If so, are we able to make progress in some direction this quarter?

+some other folks

We're actively thinking about and trying to improve this space. It's particularly difficult to find the best balance given the degree to which users don't like their phones making sound unexpectedly.

We don't yet have consensus on what our answer is. Hopefully we will this quarter. Setting NextAction to 2/20 to at least give an update.

Still working through ideas. In the meantime, we're making it so that sites that you add to your homescreen on Android can autoplay sound. https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/DW7_yxL_HjE/NlynXzRJCgAJ

[Monorail components: Programs>Alignment]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

A few ideas:

1) Allow this in locally downloaded code (for Cordova games and apps).
2) Again, going off Cordova apps, maintain (on Google's servers) an allowed URL list (devs would add their URLs to the corresponding Google Play entry, perhaps).

[Empty comment from Monorail migration]

@ojan@chromium.org: FYI added ideas in https://bugs.chromium.org/p/chromium/issues/detail?id=178297#c131 ... hopefully yer still alive.

The overall restriction here is definitely not going away, sorry - users have made it clear they don't want iframes to play audio by default without the user tapping on that frame.  But the specific use case here is reasonable - updating the summary.

We're doing (or have done) a number of things to help:

Web apps installed to the home screen will be able to play audio by default - https://crbug.com/chromium/715049.

When one frame does a postMessage into another frame, the gesture indicator flows with it - see https://crbug.com/chromium/355658.  So if RDio could wire up the code so that the play request was inside of an onmessage handler in the iframe, and the postMessage call happened as a direct result of a click then it should just work.  Does that help?

That's still quite brittle and overly restrictive though.  In https://crbug.com/chromium/696617 we're exploring relaxing user gestures significantly - there just had to be a click at SOME POINT in the past in the frame.  But in that case we'll still need some way to explicitly propagate the "user activation" state down to the iframe (we wouldn't want all ads to get audio permission by default just because somebody tapped on the parent page).  mustaq and/or iclelland are exploring ideas here.  Do you guys have a separate bug to link to for that?  Who should this bug be assigned to for tracking?

In addition we are looking at ways for some

[Monorail components: -Blink>Media>Video -Internals>Permissions>Model Blink>Input]

Your text got cut off there ^^.

Apps are designed to play music and audio without click. Apps written in e.g. Cordova should not have the same restriction as web apps in a browser window. They should have the same range of functionality as native apps.

Sorry for the cut-off - I think that was stale.  The rest of the comment covers everything I'm aware of.

Regarding Cordova, that's a good point.  Filed https://crbug.com/chromium/728330 to track that case specifically.

Also filed https://crbug.com/chromium/728334 to track the specific case this bug was originally opened for - explicit passing to an invisible subframe (though I think postMessage fixed many of those cases).

Other than all these improvements discussed here, there's no plan to eliminate the restriction entirely so calling this bug WontFix.  We should track specific cases of possible relaxations in specific bugs.

This issue was migrated from crbug.com/chromium/178297?no_tracker_redirect=1

[Multiple monorail components: Blink>Input, Blink>Media>Audio, Internals>Media>UI]
[Monorail blocked-on: crbug.com/chromium/355658, crbug.com/chromium/402044, crbug.com/chromium/696617]
[Monorail blocking: crbug.com/chromium/396645, crbug.com/chromium/423205]
[Monorail mergedwith: crbug.com/chromium/147260, crbug.com/chromium/160536, crbug.com/chromium/160543, crbug.com/chromium/235312, crbug.com/chromium/280161, crbug.com/chromium/408539, crbug.com/chromium/410226, crbug.com/chromium/423205, crbug.com/chromium/462859, crbug.com/chromium/558372, crbug.com/chromium/558425, crbug.com/chromium/705221, crbug.com/chromium/706598]
[Monorail components added to Component Tags custom field.]