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

[Ian Gilman]

This is an outdated policy that is hampering the development of cutting-edge music and game mobile webapps. There's been some discussion in the bug:

http://code.google.com/p/chromium/issues/detail?id=178297

...but no action yet to fix it. I'm wondering if anyone here has suggestions on how to proceed.

Thank you,

-- Ian

[Michael van Ouwerkerk]

The notes in the bug do suggest it is an outdated policy. The restriction is not applied in other browsers, or in Web Audio.

One suggestion for managing abuse that was not mentioned yet is this. Do not allow new playbacks to be started when the page is not in the foreground. This would hook into the page visibility feature already used to manage other APIs when the page is in background. The other APIs are: Geolocation, Device Motion, Vibration, Web RTC. Maybe more.

I'd like to support playing music in the background though. So the idea is that you can start playback when in foreground, and continue playing when the page is in background, but not start new playbacks. When (on Android) the entire browser app is in background, I assume playback stops.

Regards,

Michael

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Ian Gilman]

Yes, I agree that only foreground pages should be able to initiate sound. Not being able to know which one of your tabs is playing audio is already frustrating enough in desktop; it would be worse in mobile. 

That said, I also agree that we need a way to continue playing audio in the background. Furthermore, if the audio stream has begun and the tab is now in the background, we should be able to play the next audio file after the current one ends. I work on the JavaScript API for the Rdio streaming music service, and we have mobile web playback, but on most mobile browsers, we can't continue playing in the background after the current song ends. This means that no music streaming service on mobile can be web-only, which is a shame. The Firefox OS folks have been working on a "background app" system for webapps that would address this; it would be great to see something similar in Chrome.

-- Ian Gilman

-- digital renaissance man

-- www.iangilman.com

[Philip Jägenstedt]

I don't think it would work to allow a page to begin playing media any
time it's in the foreground and at any point after a successful
play(). All pages will be in the foreground at some point and those
that want to be naughty can just play 2 samples of silence [1] then to
get around the background tab blocking later.

Another approach we could take is an off-by-default preference that
forces preload="none" [2] until the user interacts with the
audio/video element in some way. But if it were up to me, I would
probably try to remove the restrictions altogether and learn from user
complaints what problems are actually important to solve.

[1] data:audio/wav;base64,UklGRigAAABXQVZFZm10IBAAAAABAAEARKwAAIhYAQACABAAZGF0YQQAAAAAAAAA
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#attr-media-preload

Philip

[Ian Gilman]

Agreed on removing the restrictions and seeing how it goes. They were put in place when the mobile web landscape was much different. 

-- Ian Gilman

-- digital renaissance man

-- www.iangilman.com