Intent to Ship: Allowing autoplay in WebAPK manifest scope

[Zhiqiang Zhang]

Contact emails

zqz...@chromium.org, mlam...@chromium.org, dah...@chromium.org

Spec

No spec. The change is compatible with the HTML specification.

Summary

In WebAPK mode, frames that are within the WebAPK manifest scope will be allowed to autoplay media unmuted.

Motivation

Autoplay with sound is blocked on Android, which is mainly to reduce user annoyance. As the goal of WebAPK is to close the gap between Web apps and native Android apps, it is reasonable to relax the autoplay restriction as the user installing the WebAPK is a good indication of user engagement. This will only work in WebAPK context and the same website in a regular tab wouldn’t have this feature enabled.

Interoperability and Compatibility Risk

Although there’s no other browsers shipping this feature, both the interoperability risk and compatibility risk are low as autoplaying media is optional. The UA can decide which media element should autoplay and which should be blocked, and websites should not assume autoplay will always be allowed.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Android only (in WebAPK mode). We do not ship on Android WebView as it does not apply to WebAPK.

OWP launch tracking bug

https://crbug.com/689960.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5715456904134656

Requesting approval to ship?

Yes.

--

Zhiqiang Zhang

[Philip Jägenstedt]

LGTM1, this makes a lot of sense. I assume that in general we want to minimize differences between WebAPK and in-browser content, but here there isn't really a plausible path to enabling autoplay on the web at large.

"Amusing" aside: Some web content even depends on autoplay not working on mobile :-/

[Ashley Gullen]

Could this be extended to lifting all "requires user gesture" restrictions in WebAPK scope? In our HTML5 game engine we've had on-going frustrations with the user gestures requirement for things like unmuting Web Audio, invoking downloads, opening popup windows, copying to clipboard, and others. Allowing media playback without user gesture in WebAPK scope is a great start, but why not lift the restriction from all cases?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Kenneth Rohde Christiansen]

I think it would be good to look at them individually, for instance you might not want to have the app auto connect to a Bluetooth device around you without your knowledge - this currently also requires a user gesture.

Kenneth

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[Rick Byers]

LGTM2

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[Chris Harrelson]

LGTM3

On Thu, Feb 16, 2017 at 8:35 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM2

[Owen Campbell-Moore]

FYI I owe a doc that proposes clear rationale for when we're willing to make an exception between normal browser context and installed WebAPK. 

This change LGTM though.

On Thu, Feb 16, 2017 at 9:57 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

On Thu, Feb 16, 2017 at 8:35 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM2

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[os...@rough.dk]

Great!

Would this also be able to affect YouTube embeds?

[Zhiqiang Zhang]

> Would this also be able to affect YouTube embeds?

Media elements in frames that are beyond the WebAPK scope are still not allowed to autoplay.

On Fri, Mar 24, 2017 at 10:03 AM <os...@rough.dk> wrote:

Great!

Would this also be able to affect YouTube embeds?

--

Zhiqiang Zhang

[Jeffrey Yasskin]

FWIW, removing the gesture requirement for bluetooth.requestDevice() still leaves a permission dialog between the app and connecting to a device.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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