UserAgent: Mozilla/5.0 (X11; CrOS x86_64 10323.67.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.209 Safari/537.36
Platform: 10452.42.0

Example URL:

Steps to reproduce the problem:
1. Unzip attached extension folder, goto chrome://extensions and load the folder as an unpacked extension
2. Open the newly added app called "video inside of a webview test"
3. Observe top video autoplaying and bottom video inside of a webview paused.

What is the expected behavior?
Both videos should autoplay. Since the extension is installed to Chrome, the extension should be trusted to autoplay videos regardless of muted status.

What went wrong?
The app has 2 videos embedded in it. The first video is just a <video> element, and the second is a WebView displaying an html file with the same <video> element inside. Both the html file and video file are local resources.

A script inside of the webview frame calls play() on the video element after 3 seconds. Using devtools console to inspect the WebView frame, you'll see the error:

Uncaught (in promise) DOMException: play() failed because the user didn't interact with the document first.

Both videos autoplay on 65.0.3325.184

Video in WebView frame does not autoplay on 66.0.3359.79 or 67.0.3383.0

Understanding this is likely related to the new autoplay policy: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes, in the situation of digital signage, user interaction is usually not even possible.

An example might be a device configured with a kiosk application for digital signage. The device should automatically start playing a slideshow of videos as soon as it is launched for the first time. The end user will never have interaction with the kiosk app.

Please understand that we are a Chrome partner talking specifically about kiosk applications for the Enterprise use cases of digital signage and kiosks.  https://enterprise.google.com/chrome/digital-signage/  In these scenarios user interaction is not always possible (billboards, airport fids, etc.) And content is expected to autoplay.  In fact, most of the use case is built on remote administration and NOT having to interact with the devices.  Apps installed by admins through the Admin Console, apps have the kiosk permission.  From a quick sample of apps, >60% of those I looked at are currently using webview to load their cloud cms/content.  Google's own Chrome Sign Builder also uses a webview in the same manner.

If there is a new way we are supposed to approach this, I have not seen it communicated or documented. From our testing this autoplay change will affect Enterprise customers.

These are not just Windows/Linux boxes running Chrome.  We are talking about Chrome OS devices where we don't have access to command line flags or group policies.  They are remotely administered via the Google Admin console/Chrome Enterprise Management.

This is a similar issue to  crbug.com/821284  but with WebViews instead of IFrames.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? N/A 

Did this work before? Yes 65.0.3325.184

Does this work in other browsers? N/A

Chrome version: 66.0.3359.79  Channel: beta
OS Version: 10452.42.0
Flash Version: 

At the time of writing this,  crbug.com/821284  has been fixed but rejected for merge since M66 Stable release is tomorrow. This is a similar issue and will break a large amount of Enterprise Chrome Kiosk users that utilize videos with audio in their applications.
 

Deleted: webview (2).zip 970 KB

webview (2).zip 970 KB Download