Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 178297 Android Chrome does not allow applications to play HTML5 audio without an explicit action by the user
Starred by 228 users Reported by iangil...@gmail.com, Feb 26 2013 Back to list

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-03-31
OS: Android
Pri: 2
Type: Bug
Team-Security-UX

Blocking:
issue 396645
issue 423205

Restricted
  • Only users with EditIssue permission may comment.


Hotlists containing this issue:
test
Top-Starred-Bugs


Sign in to add a comment
Example URL:
http://iangilman.com/rdio/chrome-audio/

Steps to reproduce the problem:
Android Chrome restricts playback of HTML5 audio; you need to call .play() from within a click handler or such. This is an explicit feature, and has been discussed in http://code.google.com/p/chromium/issues/detail?id=138132 . The comment at the end of that bug says to file a new bug if adding new information, so that's what I'm doing here.

I work for http://rdio.com, and we'd like to provide mobile playback with our new JavaScript API. Due to our relationship with the music labels, we can't just pass out .MP3 URLs, but instead must handle playback ourselves. For this reason (and others) our JS API creates a non-visible rdio.com iframe on the API client's site, and we do our playback (among other things) within that iframe.

This structure works great on desktop, but with Android Chrome it's simply not possible for us to trigger playback from within the click handler. Here's the sequence:

1. User clicks
2. We postMessage into the iframe
3. Inside the iframe we do an ajax call to get the MP3 url
4. Inside the iframe we play the MP3

I've mocked this up in a simplified version for testing here:

http://iangilman.com/rdio/chrome-audio/

I realize our scenario may be a bit unusual, but I think it highlights one of the ways in which this playback restriction is a hindrance to users of the Android Chrome browser.

What is the expected behavior?
There should be some way to play audio in this scenario. I'm in favor of removing the restriction entirely, but even some way to keep track that the postMessage/Ajax chain started with a click would be better than nothing.

What went wrong?
See above.

Did this work before? No 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes Opera Mobile

Chrome version: 18.0.1025469  Channel: stable
OS Version: 4.2
 
Status: Untriaged
Confirmed on Nexus 7 Device, on Chrome for Android Stable and Beta
Status: Available
Project Member Comment 3 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Feature-Media Cr-Internals-Media
Comment 4 by vbgu...@gmail.com, Mar 17 2013
I am able to duplicate this for Chrome 25 for Samsung Galaxy S3 running Android 4.1
Comment 5 by phate6...@gmail.com, May 10 2013
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?
Comment 10 by phil...@opera.com, Nov 12 2013
Cc: acolwell@chromium.org qin...@chromium.org scherkus@chromium.org
Labels: Cr-Blink-Video
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.
Comment 11 by phil...@opera.com, Nov 12 2013
Cc: m...@opera.com
@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? 
Comment 13 by m...@opera.com, Nov 14 2013
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.
Comment 16 by m...@opera.com, Jan 20 2014
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) :-(

Comment 17 by phil...@opera.com, Feb 10 2014
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/
Cc: dalecur...@chromium.org
Issue 235312 has been merged into this issue.
Cc: punyabrata@chromium.org
Issue 280161 has been merged into this issue.
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.
Cc: strobe@chromium.org
Owner: klo...@chromium.org
Comment 22 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.
Comment 24 by phil...@opera.com, Feb 20 2014
Issue 160536 has been merged into this issue.
Comment 25 by phil...@opera.com, Feb 20 2014
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.
Cc: jluther@chromium.org
Cc: miguelg@chromium.org
Issue 160543 has been merged into this issue.
Issue 147260 has been merged into this issue.
Labels: -Cr-Internals-Media Cr-Internals-Media-UI Cr-Blink-Audio
Status: Assigned
Cc: vinodkr@chromium.org
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.
Comment 32 by phil...@opera.com, Mar 8 2014
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 33 Deleted
yes
>> Sorry for cutting in.
>> Do I only have to set the user_gesture_required_for_media_playback flag to false so as to enable autoplay for Android ?
>> The autoplay function is needed for the device like a kiosk
>
>yes
>
I got it. Thank you !
Comment 36 by Deleted ...@, May 13 2014
Any update on this topic? We are seeking for a solution that somehow the mobile web browser could automatically start playing the movie material. It was really frustrated since we've been searching around the internet for weeks with no luck. Anyone who could provide any hints would be much appreciated! 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. 
Comment 38 Deleted
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.
Comment 40 by Deleted ...@, May 13 2014
@bartonph: Yes, I can do that for my own browser, but if I want to write a game in html5 for example, I cannot turn that on for my players. That means that I can't play sound effects on mobile without the user touching the screen.
@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!
Comment 44 by du...@edu-soft.eu, May 15 2014
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.
Comment 46 by phil...@opera.com, Jul 22 2014
There's a review up for this now: https://codereview.chromium.org/414543002/
Cc: klo...@chromium.org
Owner: abarth@chromium.org
Cc: jdduke@chromium.org
Cc: palmer@chromium.org
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.
Project Member Comment 51 by bugdroid1@chromium.org, Jul 23 2014
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.
Comment 53 by boliu@chromium.org, Jul 23 2014
Blocking: chromium:396645
Project Member Comment 54 by bugdroid1@chromium.org, Aug 1 2014
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:
> 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

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

Review URL: https://codereview.chromium.org/428263004
-----------------------------------------------------------------
Comment 55 by phil...@opera.com, Aug 1 2014
Hopefully something can be learned from that data that would help improve the implementation if it can't simply be removed...
Project Member Comment 57 by bugdroid1@chromium.org, Aug 8 2014
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


Project Member Comment 58 by bugdroid1@chromium.org, Aug 8 2014
------------------------------------------------------------------
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
-----------------------------------------------------------------
Project Member Comment 59 by bugdroid1@chromium.org, Aug 8 2014
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:
> 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
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=288308

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


Project Member Comment 60 by bugdroid1@chromium.org, Aug 8 2014
------------------------------------------------------------------
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:
> 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
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=288308

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

Review URL: https://codereview.chromium.org/453023002
-----------------------------------------------------------------
Cc: abarth@chromium.org
Owner: ----
Status: Available
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.
Comment 63 by phil...@opera.com, Aug 11 2014
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.
Comment 65 by phil...@opera.com, Aug 14 2014
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.
Comment 67 by m...@alum.mit.edu, Aug 22 2014
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.
Comment 70 by Deleted ...@, Aug 22 2014
The point that was mentioned in #20 is the main thing: There is a work-around using the Web Audio API that already allows/forces us (developers/websites) to download the whole file (all files) and play them whenever we want, without needing user interaction. This basically makes the limitation on <audio> elements not being able to call play() without user interaction simply an inconvenience for developers and provides no real added benefit/safety for users. And like was pointed out, may actually be worse, since the whole file needs to be downloaded first using the Web Audio API. And this method would likely lead to a developer downloading all files in advance to make it easier to work with.
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.
Labels: Cr-Security-UX
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.
Issue 410226 has been merged into this issue.
It's things like this that make me miss programming in COBOL.
Comment 79 by toml...@gmail.com, Oct 9 2014
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.
Blockedon: chromium:402044
Issue 408539 has been merged into this issue.
Blocking: chromium:423205
Issue 423205 has been merged into this issue.
Cc: -acolwell@chromium.org
Wouldn't it make sense to extend the bug to include HTML video too? It's basically the same thing, isn't it?
Comment 86 by phil...@opera.com, Oct 30 2014
Yes, the restrictions are exactly the same for audio and video.
Comment 87 Deleted
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 issue 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.
Cc: -palmer@chromium.org
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.
Comment 97 by f...@chromium.org, Feb 4 2015
Cc: egm@chromium.org
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.
Comment 100 by m...@rcel.cz, Feb 13 2015
- 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.

Cc: -scherkus@chromium.org
#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 Issue 424174, make Android Chrome almost unusable for any kind of multimedia experience at the moment.
Cc: -m...@opera.com -jluther@chromium.org
#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 Issue 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.
Comment 109 by phil...@opera.com, Apr 29 2015
#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 Issue 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?
Comment 113 by c...@knoblach.de, Oct 3 2015
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

Issue 462859 has been merged into this issue.
Comment 116 Deleted
Labels: Restrict-AddIssueComment-EditIssue
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.
Cc: kerz@chromium.org
Issue 558425 has been merged into this issue.
Issue 558372 has been merged into this issue.
Components: -Blink>Audio Blink>Media>Audio
Renaming Blink>Audio to Blink>Media>Audio for better characterization
Components: -Blink>Video Blink>Media>Video
Renaming Blink>Video to Blink>Media>Video for better characterization
Labels: Proj-Autoplay
Labels: Needs-BlinkMediaTriage
Components: -Security>UX Internals>Permissions>Model
Components: -Security>UX Internals>Permissions>Model
Cc: kenjibaheux@chromium.org ojan@chromium.org
+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?
Cc: dominickn@chromium.org dah...@chromium.org kcaratt...@chromium.org markdavidscott@google.com
NextAction: 2017-02-20
+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.
Components: Programs>Alignment
NextAction: 2017-03-31
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
Cc: jmukthavaram@chromium.org mlamouri@chromium.org
Issue 705221 has been merged into this issue.
Issue 706598 has been merged into this issue.
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).
Comment 132 by mlamouri@chromium.org, Apr 19 (4 days ago)
Labels: -Needs-BlinkMediaTriage
Sign in to add a comment