New issue
Advanced search Search tips
Starred by 50 users
Status: Started
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 714676
issue 729518

issue 721707
issue 747616
issue 752472
issue 776011
issue 714156
issue 715051
issue 779087

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment
Implement Unified Autoplay policy
Project Member Reported by, Apr 25 2017 Back to list
Blocking: 715051
Blocking: 714156
Blocking: -714156
Blocking: 714156
 Issue 714156  has been merged into this issue.
Blocking: 721707
Project Member Comment 6 by, May 31 2017
The following revision refers to this bug:

commit e6850ab7401a3124a61684aaabb063e8dabb23ee
Author: Mounir Lamouri <>
Date: Wed May 31 17:56:22 2017

Unified Autoplay: implement document user gesture restriction in Blink.

This is adding a new AutoplayPolicy in Blink that checks if the document
received a user gesture. It applies to <audio> and <video>.

Presubmit is ignored because pointerActionSequence does not support
keyboard events yet and this is required for the test.


Change-Id: Ie20d44d90fe8850c0e59aad5bcbef7ca4d2768d3
Reviewed-by: Daniel Cheng <>
Reviewed-by: Mustaq Ahmed <>
Commit-Queue: Mounir Lamouri <>
Cr-Commit-Position: refs/heads/master@{#475960}

Project Member Comment 7 by, Jun 2
The following revision refers to this bug:

commit c0c7c848443d90a45fc3dfcba0820cfbe82ea5f7
Author: Mounir Lamouri <>
Date: Fri Jun 02 14:44:06 2017

Implement autoplay DocumentActivation policy for Web Audio.

This is implementing the Web Audio side of the document activation
policy. The policy is not available by default and it might change
slightly but most likely, BaseAudioContext wouldn't have to change.

Bug: 715049
Change-Id: I61ba9331ab51c3765ec4731c096826e9a96b4758
Commit-Queue: Mounir Lamouri <>
Reviewed-by: Raymond Toy <>
Reviewed-by: Ilya Sherman <>
Cr-Commit-Position: refs/heads/master@{#476642}

Blockedon: 729518
Project Member Comment 9 by, Jun 6
The following revision refers to this bug:

commit 431bb4ec952257a3a60c3554fdf039d0692a0b64
Author: mlamouri <>
Date: Tue Jun 06 08:54:24 2017

Autoplay: add document user activation flag in chrome://flags

This is plumbing the flag to Blink. The feature is not fully implemented
but can be tested. The missing parts are:
- Media Engagement Index;
- Iframe delecation;
- Sticky bit across navigations.


Cr-Commit-Position: refs/heads/master@{#477238}


FYI it doesn't work on facebook videos. Once I scroll down to them, they start buffering and playing.
Maybe you can share more information? Was that on mobile or desktop? What did you do to test? Were the videos playing with sound?
Desktop. Scroll down to this page - until you reach Posts section where you will see the first video that starts laying and buffering. The sound was muted by the browser, emulating android's behavior. Before you test make sure Autoplay setting for your facebook profile is set to ON. The setting can be found here -

Okay I tested it again right now. I can't reproduce it. But if I browse to another page and come back by clicking back button to come back to that page it happens again. I think a race condition is at play(no pun intended) here.
Comment 14 Deleted
Doesn't work on embedded Youtube videos either where autoplay is forced in the URL like "autoplay=1&", example - At the extreme right corner notice the embedded video starts buffering or sometimes playing too.

Also I tested on facebook again and out of 3 times it autoplayed/buffered twice.
Broken in v61.0.3145.0!! Th setting "Document user activation is required" is not working.
In 61.0.3163.31 (Official Build) beta (64-bit) the hidden setting "document user activation is required" is not working.

I am often on a bandwidth-constrained link and automatically playing videos is a price burden.
I'm now on Chromium version 62.0.3186.0 (Official Build) (64-bit) and it doesn't work on the homepage of IGN - Scroll down the page a bit and you will find an autoplaying media even when "Document user activation is required" setting is already in place.
Regarding #62, I've just tried and the videos seem to be playing as muted. Autoplay muted will always be allowed as the intent here isn't to reduce annoyance.
Why allow as muted ? They still consume bandwidth and are an annoyance which is the very reason you started this so to put an end to "autplaying without user's consent" annoyance and now you're contracdicting yourself ?

Also this contradicts the very setting "Document user activation is required" 

I NEVER have any consent to play that video and yet it is playing!!
I understand your frustration and indeed, this is painful that a website can download tons of data without you being fully aware. However, blocking autoplay muted wouldn't solve this. Websites have been using counter measures on mobile to avoid this restriction such as using GIFs or simply decode videos in a <canvas>. These two solutions are worse by all means. The Web platform can't block things from being displayed on the screen. We are looking at other solutions to prevent websites from using too much data in data constrained context. Something you can start with is to turn on Data Saver (or download the extension on desktop).
This feature should make control of bandwidth usage to who pays for it -- the user.

No video should be allowed, even muted, if the payer of bandwidth does not want to.
No you don't understand it at all, and please don't pretend like you do, otherwise I wouldn't even be here complaining about it. Also I already have Data Saver and guess what it's only useful if the video is being streamed from a http website, but most of the websites are HTTPS now and that makes Data Saver useless in the first place ! So please keep your suggestions to yourself.

What you did here right now is HALF MEASURE. If you can't fix the mute autoplay issue then say it honestly but please don't serve me some Google agenda here and if you and the team doesn't want to fix it deliberately then say it and end this thing. I hate being trolled by some bullshit which is not only unbelievable  but contradicts the very existence of this AutoPlay policy. Also it's not just about bandwidth, why should any video play without my consent ? That's it. It's that simple! 
I don't think anger helps but I agree that autoplay should be completely blocked. GIFs already don't play on mobile without me explicitly playing them. They have the circle with the word "GIF" inside that I have to tap to start them. As for canvas, there must be a way to block rapid updates to a canvas without user consent. You could simply track the frequency of renders and if it receives too many within a given one second time frame then it could block further updates until it has received user approval. Idk, just spitballing here.

The canvas thing can be a separate issue but I don't think that the lack of protection there should prevent autoplay from being completely blocked. At least it increases the barrier for those bad actors that still want to try autoplay which means a lot fewer will - especially if there are plans to block frequent unauthorized canvas updates too.
I completely appreciate that you're concerned about starting an arms wars with website developers. My view is that this is a battle worth fighting. The web is mobile now. Your users find it annoying and pay for bandwidth. We want this.

Sites that respect their users won't try to circumvent their clear preferences. Stopping autoplay entirely will immediately improve the browsing experience and save tons of money for a vast number of your users. Surely you have metrics supporting this.

For scummy sites that don't respect their users preferences, we have content/ad blockers-- even though Chrome doesn't support them on mobile just yet.
If you go to the video plays unmuted even with Document user Activation is Required. Somehow the policy in Firefox manages to block video and audio on this same page with a unified policy.
Safari on MacOS High Sierra offers users the option to either mute autoplay video or stop it from autoplaying entirely.

Firefox has supported this feature since version 41 in 2015 with its media.autoplay.enabled config flag.

Once MacOS High Sierra is released, Chrome will be the only browser _not_ to allow its users to block autoplaying HTML5 video.
A wild guess: Google sells video ads and it wants to minimize the impact on that business.

Given Chrome's market share, it's able to continue with its autoplay-if-muted stance -- for now -- without concerning itself with what FF or Safari are or are not doing.
I'm appreciative that Google (and co) are trying to make Chrom(ium)e act smartly by default, without users having to figure out the right settings all the time. I suspect, however, that the "smartest" thing to do is also the simplest -- to completely disallow autoplay (sometimes called Click To Play). 

I also understand the issues seen, where merely disallowing autoplay on <video> and <audio> is insufficient (rendering videos on a <canvas>, for example). However, one can set the policy as "we disallow autoplay", and start by blocking autoplay on audio and video tags. Possible solutions for canvas can come later, or never! Maybe just only block audio and video tags' autoplay. It's possible the potential problem w/canvas doesn't need solving. 

The main point here is that the control should always be in the hands of the user. Browsers weren't originally called User Agents for nothing, and in general I think it's a good idea to follow a principle of least surprise. 

As for direct feedback on the Unified Autoplay Policy linked in Comment 1:

I would propose a change: block autoplay (including muted autoplay) completely, by default. With a User Gesture (for the eTLD+1), autoplay muted could be enabled if the heuristic is below the threshold. With a high engagement heuristic (over the threshold) AND a User Gesture on record, autoplay could be enabled with sound. This would put the policy more fully in alignment with users' interests, while not completely blowing up "the ecosystem". 

The current policy doesn't make any sense, and I think will result in autoplay /with sound/ being enabled much more often than the document authors are expecting. I'm open to data to the contrary, but I think users hate this (except on youtube or other video sites that would be largely unaffected by any of these policy changes). 
A personal anecdote: I've recently switched from Chromium to Brave as my daily browser, and the #1 reason for doing this was autoplay.

Unwanted videos, distracting, burning up bandwidth, with embarrassing unwanted sound, appearing on more and more pages. This happened even in background tabs, and there seems to be no way to prevent it from happening. Used to run the "Disable HTML5 Autoplay" extension, but it recently broke, as it can't keep up with all the ways that video can be autoplayed these days.

I am keeping Chromium, but only going back to it when using Google Apps and other Google services that really benefit from the homefield advantage of Chromium. However, it's Brave for me by default now, and been happier and calmer ever since those video popups have stopped.

Guessing that I'm not the only one feeling this way. I'd love to be able to come back to Chromium.

I sadly think Google can not separate its ad revenue desires from it's "serve the user" desires and this issue is never going to go away. There is one simple solution. I will be going to Firefox. When/If Google decides that it wants to be a part of the browser experience for the internet and give us back control over unwanted content, then I'll come back. Until then, see you on the flip side.

I don't know if it's the place, but what I really miss is a unifed and synchronous way of knowing if sound is authorized ?

if (!window.document.audioAuthorized) {do things}

window.document.addEventListener('audioAuthorized', function(e){console.log(window.document.audioAuthorized)})

So that we know the state, instead of "guessing the state"

The unified autoplay policy does not work on, perhaps the web's most egregious offender of annoyingly insisting on autoplaying videos with sound contrary to their users' overwhelming preferences.
Auto-buffering still remains an issue where autoplay is disabled, for example -
Blocking: 747616
Blocking: 752472
Blocking: 776011
Can someone explain me how can I block the autoplay of videos in Chrome?

It doesn't appear they're going to offer a global off button for autoplay. Seems like Google is choosing ad revenue (vids get higher $$$) over the users. I have my autoplay set to "Document user activation required", which seems to stop most (but not all) first-time-to-page autoplay, but allows videos to run if I've been to the site before. This still sucks, but is better than nothing?

(Version 62.0.3202.62 (Official Build) (64-bit))
I'm in Chrome 62.0.3202.62 64-bit and I can't find a setting called "Document user activation required".  Where did you find it?
Project Member Comment 41 by, Oct 26
The following revision refers to this bug:

commit c9d234ccd01690deaeba611d6e13d9105b68c025
Author: Mounir Lamouri <>
Date: Thu Oct 26 17:09:34 2017

Autoplay: add Feature flag to turn on unified autoplay policy.

Bug: 715049
Change-Id: I5fd2e635fe686ad50bb1bc22ae2a1ca0b64a4246
Reviewed-by: Becca Hughes <>
Reviewed-by: Dale Curtis <>
Commit-Queue: Mounir Lamouri <>
Cr-Commit-Position: refs/heads/master@{#511856}

Re comment #40, you can find "autoplay policy" in chrome://flags.
Blocking: 779087
The problem with selecting "Document user activation required" is that yes it stops some auto-playing videos, but it also doesn't offer me any way of allowing it on selected sites (i.e. YouTube, Netflix).  So now my browser simply won't play anything anywhere.  I looked to the location bar and in site settings, but found nothing to enable video playback on a specific site.
Labels: -M-61 M-65
Sign in to add a comment