New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 227 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-03-31
OS: Android
Pri: 2
Type: Bug

Blocked on:
issue 696617
issue 355658
issue 402044

Blocking:
issue 396645
issue 423205

Restricted
  • Only users with EditIssue permission may comment.


Show other hotlists

Hotlists containing this issue:
Top-Starred-Bugs


Sign in to add a comment
link

Issue 178297: Android Chrome does not allow applications to play HTML5 audio without an explicit action by the user

Reported by iangil...@gmail.com, Feb 26 2013

Issue description

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
 
Showing comments 37 - 136 of 136 Older

Comment 37 by bartonph...@gmail.com, May 13 2014

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

Comment 39 by bartonph...@gmail.com, May 13 2014

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.

Comment 41 by ashlaa...@gmail.com, May 13 2014

@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.

Comment 42 by iangil...@gmail.com, May 13 2014

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.

Comment 43 by chatango...@gmail.com, May 13 2014

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)"

Comment 45 by guruofxw...@gmail.com, Jul 15 2014

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/

Comment 47 by abarth@chromium.org, Jul 22 2014

Cc: klo...@chromium.org
Owner: abarth@chromium.org

Comment 48 by jdduke@chromium.org, Jul 23 2014

Cc: jdduke@chromium.org

Comment 49 by jdduke@chromium.org, Jul 23 2014

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).

Comment 50 by ashlaa...@gmail.com, Jul 23 2014

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.

Comment 51 by bugdroid1@chromium.org, Jul 23 2014

Project Member
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
-----------------------------------------------------------------

Comment 52 by qin...@chromium.org, Jul 23 2014

The fix affects android webview as setMediaPlaybackRequiresUserGesture API now useless.

Comment 53 by boliu@chromium.org, Jul 23 2014

Blocking: chromium:396645

Comment 54 by bugdroid1@chromium.org, Aug 1 2014

Project Member
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...

Comment 57 by bugdroid1@chromium.org, Aug 8 2014

Project Member
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

Comment 58 by bugdroid1@chromium.org, Aug 8 2014

Project Member
------------------------------------------------------------------
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
-----------------------------------------------------------------

Comment 59 by bugdroid1@chromium.org, Aug 8 2014

Project Member
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

Comment 60 by bugdroid1@chromium.org, Aug 8 2014

Project Member
------------------------------------------------------------------
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
-----------------------------------------------------------------

Comment 61 by abarth@chromium.org, Aug 8 2014

Cc: abarth@chromium.org
Owner: ----
Status: Available

Comment 62 by jamesfos...@gmail.com, Aug 9 2014

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...

Comment 64 by abarth@chromium.org, Aug 11 2014

> 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.

Comment 66 by cypher...@gmail.com, Aug 22 2014

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.

Comment 68 by ashlaa...@gmail.com, Aug 22 2014

> 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?

Comment 69 by cypher...@gmail.com, Aug 22 2014

> 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.

Comment 71 by guruofxw...@gmail.com, Aug 23 2014

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.

Comment 72 by markus.h...@gmail.com, Aug 25 2014

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.

Comment 73 by andyearn...@gmail.com, Sep 3 2014

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.

Comment 74 by palmer@chromium.org, Sep 3 2014

Labels: Cr-Security-UX
darin, klobag, felt: Where should we be on this?

Comment 75 by kofichar...@gmail.com, Sep 3 2014

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???

Comment 76 by klo...@chromium.org, Sep 3 2014

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.

Comment 77 by scherkus@chromium.org, Sep 3 2014

Issue 410226 has been merged into this issue.

Comment 78 by thehicks...@gmail.com, Sep 20 2014

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.

Comment 80 by dalecur...@chromium.org, Oct 22 2014

Blockedon: chromium:402044

Comment 81 by scherkus@chromium.org, Oct 29 2014

 Issue 408539  has been merged into this issue.

Comment 82 by scherkus@chromium.org, Oct 29 2014

Blocking: chromium:423205

Comment 83 by klo...@chromium.org, Oct 29 2014

 Issue 423205  has been merged into this issue.

Comment 84 by acolwell@chromium.org, Oct 29 2014

Cc: -acolwell@chromium.org

Comment 85 by markus.h...@gmail.com, Oct 30 2014

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

Comment 88 by darin@chromium.org, Dec 7 2014

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

Comment 89 by agamem...@gmail.com, Dec 7 2014

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.

Comment 90 by ashlaa...@gmail.com, Feb 3 2015

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.

Comment 91 by klo...@chromium.org, Feb 3 2015

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.

Comment 92 by ashlaa...@gmail.com, Feb 3 2015

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).

Comment 93 by b.kele...@samsung.com, Feb 4 2015

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.

Comment 94 by palmer@chromium.org, Feb 4 2015

Cc: -palmer@chromium.org

Comment 95 by jamesfos...@gmail.com, Feb 4 2015

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.

Comment 96 by jamesfos...@gmail.com, Feb 4 2015

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

Comment 98 by matteosi...@gmail.com, Feb 5 2015

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.

Comment 99 by agamem...@gmail.com, Feb 5 2015

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.

Comment 101 by scherkus@chromium.org, Apr 21 2015

Cc: -scherkus@chromium.org

Comment 102 by konisteh...@gmail.com, Apr 25 2015

#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.

Comment 103 by qin...@chromium.org, Apr 27 2015

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.

Comment 104 by jamesfos...@gmail.com, Apr 28 2015

#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.

Comment 105 by qin...@chromium.org, Apr 28 2015

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.

Comment 106 by jamesfos...@gmail.com, Apr 29 2015

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?

Comment 107 by qin...@chromium.org, Apr 29 2015

#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.

Comment 108 by konisteh...@gmail.com, Apr 29 2015

#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.

Comment 110 by konisteh...@gmail.com, Apr 29 2015

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

Comment 111 by jamesfos...@gmail.com, Apr 30 2015

#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.

Comment 112 by ivan.kuc...@gmail.com, Jul 19 2015

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

Comment 114 by seeingwi...@gmail.com, Oct 4 2015

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

Comment 115 by phil...@opera.com, Nov 2 2015

 Issue 462859  has been merged into this issue.

Comment 116 Deleted

Comment 117 by palmer@chromium.org, Nov 2 2015

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.

Comment 118 by krav...@chromium.org, Nov 19 2015

Cc: kerz@chromium.org
 Issue 558425  has been merged into this issue.

Comment 119 by cbiesin...@chromium.org, Nov 24 2015

 Issue 558372  has been merged into this issue.

Comment 120 by sshru...@google.com, Mar 21 2016

Components: -Blink>Audio Blink>Media>Audio
Renaming Blink>Audio to Blink>Media>Audio for better characterization

Comment 121 by sshru...@google.com, Mar 21 2016

Components: -Blink>Video Blink>Media>Video
Renaming Blink>Video to Blink>Media>Video for better characterization

Comment 122 by renganat...@chromium.org, May 11 2016

Labels: Proj-Autoplay

Comment 123 by mlamouri@chromium.org, Aug 9 2016

Labels: Needs-BlinkMediaTriage

Comment 124 by lgar...@chromium.org, Nov 22 2016

Components: -Security>UX Internals>Permissions>Model

Comment 125 by lgar...@chromium.org, Nov 22 2016

Components: -Security>UX Internals>Permissions>Model

Comment 126 by dk...@chromium.org, Jan 23 2017

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?

Comment 127 by ojan@chromium.org, Jan 23 2017

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.

Comment 128 by ojan@chromium.org, Feb 24 2017

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

Comment 129 by mlamouri@chromium.org, Mar 29 2017

Cc: jmukthavaram@chromium.org mlamouri@chromium.org
 Issue 705221  has been merged into this issue.

Comment 130 by mlamouri@chromium.org, Mar 30 2017

 Issue 706598  has been merged into this issue.

Comment 131 by agamem...@gmail.com, Mar 30 2017

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 2017

Labels: -Needs-BlinkMediaTriage

Comment 133 by agamem...@gmail.com, Apr 30 2017

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

Comment 134 by rbyers@chromium.org, May 24 2017

Blockedon: 355658 696617
Cc: iclell...@chromium.org mustaq@chromium.org
Components: -Blink>Media>Video -Internals>Permissions>Model Blink>Input
Summary: Can't delegate the gesture for playing audio on Android to a cross-origin iframe (was: Android Chrome does not allow applications to play HTML5 audio without an explicit action by the user)
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 -  issue 715049 .

When one frame does a postMessage into another frame, the gesture indicator flows with it - see  issue 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 issue 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

Comment 135 by agamem...@gmail.com, May 24 2017

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.

Comment 136 by rbyers@chromium.org, May 31 2017

Owner: mlamouri@chromium.org
Status: WontFix (was: Available)
Summary: Android Chrome does not allow applications to play HTML5 audio without an explicit action by the user (was: Can't delegate the gesture for playing audio on Android to a cross-origin iframe )
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  issue 728330  to track that case specifically.

Also filed issue 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.
Showing comments 37 - 136 of 136 Older

Sign in to add a comment