New issue
Advanced search Search tips

Issue 715049 link

Starred by 56 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug


Sign in to add a comment

Implement Unified Autoplay policy

Project Member Reported by mlamouri@chromium.org, Apr 25 2017

Issue description

Blocking: 715051
Blocking: 714156
Blocking: 714156
Cc: kkaluri@chromium.org mustaq@chromium.org mlamouri@chromium.org rbyers@chromium.org
 Issue 714156  has been merged into this issue.
Blocking: -714156
Blocking: 721707
Project Member

Comment 6 by bugdroid1@chromium.org, May 31 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6850ab7401a3124a61684aaabb063e8dabb23ee

commit e6850ab7401a3124a61684aaabb063e8dabb23ee
Author: Mounir Lamouri <mlamouri@chromium.org>
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.

BUG= 715049 
NOPRESUBMIT=true
R=dcheng@chromium.org, mustaq@chromium.org

Change-Id: Ie20d44d90fe8850c0e59aad5bcbef7ca4d2768d3
Reviewed-on: https://chromium-review.googlesource.com/507747
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475960}
[add] https://crrev.com/e6850ab7401a3124a61684aaabb063e8dabb23ee/third_party/WebKit/LayoutTests/media/autoplay/document-user-activation.html
[add] https://crrev.com/e6850ab7401a3124a61684aaabb063e8dabb23ee/third_party/WebKit/LayoutTests/media/autoplay/resources/document-user-activation-iframe.html
[modify] https://crrev.com/e6850ab7401a3124a61684aaabb063e8dabb23ee/third_party/WebKit/Source/core/html/media/AutoplayPolicy.cpp
[modify] https://crrev.com/e6850ab7401a3124a61684aaabb063e8dabb23ee/third_party/WebKit/Source/core/html/media/AutoplayPolicy.h
[modify] https://crrev.com/e6850ab7401a3124a61684aaabb063e8dabb23ee/third_party/WebKit/Source/core/testing/InternalSettings.cpp
[modify] https://crrev.com/e6850ab7401a3124a61684aaabb063e8dabb23ee/third_party/WebKit/public/web/WebSettings.h

Project Member

Comment 7 by bugdroid1@chromium.org, Jun 2 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c0c7c848443d90a45fc3dfcba0820cfbe82ea5f7

commit c0c7c848443d90a45fc3dfcba0820cfbe82ea5f7
Author: Mounir Lamouri <mlamouri@chromium.org>
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
Reviewed-on: https://chromium-review.googlesource.com/519322
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Raymond Toy <rtoy@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#476642}
[modify] https://crrev.com/c0c7c848443d90a45fc3dfcba0820cfbe82ea5f7/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.cpp
[modify] https://crrev.com/c0c7c848443d90a45fc3dfcba0820cfbe82ea5f7/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.h
[modify] https://crrev.com/c0c7c848443d90a45fc3dfcba0820cfbe82ea5f7/third_party/WebKit/Source/modules/webaudio/BaseAudioContextTest.cpp
[modify] https://crrev.com/c0c7c848443d90a45fc3dfcba0820cfbe82ea5f7/tools/metrics/histograms/histograms.xml

Blockedon: 729518
Project Member

Comment 9 by bugdroid1@chromium.org, Jun 6 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/431bb4ec952257a3a60c3554fdf039d0692a0b64

commit 431bb4ec952257a3a60c3554fdf039d0692a0b64
Author: mlamouri <mlamouri@chromium.org>
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.

BUG= 715049 

Review-Url: https://codereview.chromium.org/2921273002
Cr-Commit-Position: refs/heads/master@{#477238}

[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/chrome/browser/about_flags.cc
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/content/public/common/common_param_traits_macros.h
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/content/public/common/web_preferences.h
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/content/renderer/render_view_impl.cc
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/media/base/media_switches.cc
[modify] https://crrev.com/431bb4ec952257a3a60c3554fdf039d0692a0b64/media/base/media_switches.h

Comment 10 by sscar...@gmail.com, Jun 24 2017

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?

Comment 12 by sscar...@gmail.com, Jun 25 2017

Desktop. Scroll down to this page - https://www.facebook.com/DonaldTrump/?hc_ref=NEWSFEED&fref=nf 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 - https://www.facebook.com/settings?tab=videos


Comment 13 by sscar...@gmail.com, Jun 25 2017

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

Comment 15 by sscar...@gmail.com, Jun 27 2017

Doesn't work on embedded Youtube videos either where autoplay is forced in the URL like "autoplay=1&", example - http://omegaunderground.com/ 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.

Comment 18 by sscar...@gmail.com, Aug 15 2017

I'm now on Chromium version 62.0.3186.0 (Official Build) (64-bit) and it doesn't work on the homepage of IGN - www.ign.com. 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 ign.com and the videos seem to be playing as muted. Autoplay muted will always be allowed as the intent here isn't to reduce annoyance.

Comment 20 by sscar...@gmail.com, Aug 15 2017

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

Comment 22 by m...@borsetti.com, Aug 15 2017

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.

Comment 23 by sscar...@gmail.com, Aug 15 2017

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.

Comment 25 by s...@jacktin.com, Aug 15 2017

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.

Comment 26 by cdg...@gmail.com, Aug 17 2017

If you go to http://www.espn.com/nfl/story/_/id/20361031/chick-fil-atlanta-falcons-home-closed-sundays 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.

Comment 27 by s...@jacktin.com, Aug 17 2017

Safari on MacOS High Sierra offers users the option to either mute autoplay video or stop it from autoplaying entirely. 

https://techcrunch.com/2017/06/05/auto-play-block/

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.

Comment 28 by tod...@gmail.com, Aug 17 2017

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

Comment 30 by krel...@gmail.com, Aug 19 2017

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.

Comment 32 by p...@sketchfab.com, Sep 11 2017

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"


Comment 33 by s...@jacktin.com, Oct 13 2017

The unified autoplay policy does not work on CNN.com, perhaps the web's most egregious offender of annoyingly insisting on autoplaying videos with sound contrary to their users' overwhelming preferences.

http://www.cnn.com/2017/10/13/opinions/trump-and-the-competent-four-dantonio/index.html

Comment 34 by sscar...@gmail.com, Oct 22 2017

Auto-buffering still remains an issue where autoplay is disabled, for example - http://omegaunderground.com/
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))

Comment 40 by vphan...@gmail.com, Oct 26 2017

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 bugdroid1@chromium.org, Oct 26 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9d234ccd01690deaeba611d6e13d9105b68c025

commit c9d234ccd01690deaeba611d6e13d9105b68c025
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Thu Oct 26 17:09:34 2017

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

Bug:  715049 
Change-Id: I5fd2e635fe686ad50bb1bc22ae2a1ca0b64a4246
Reviewed-on: https://chromium-review.googlesource.com/738098
Reviewed-by: Becca Hughes <beccahughes@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511856}
[modify] https://crrev.com/c9d234ccd01690deaeba611d6e13d9105b68c025/media/base/media_switches.cc
[modify] https://crrev.com/c9d234ccd01690deaeba611d6e13d9105b68c025/media/base/media_switches.h

Re comment #40, you can find "autoplay policy" in chrome://flags.
Blocking: 779087

Comment 44 by vphan...@gmail.com, Oct 28 2017

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
Blockedon: 802330

Comment 47 by r...@cfcl.com, Feb 23 2018

I'm running Chrome 64 on OSX Yosemite (10.10.5). I recently tried setting the "Autoplay policy" setting (chrome://flags/#autoplay-policy) to "Document user activation is required".  Unfortunately, it malfunctioned in various ways, eg:

- On Huffington Post, it didn't affect the video,
  but turned off audio completely (with no recourse).

- On CNN Politics, it didn't affect either the video or the audio.

Ironically, it also failed to block either the audio or video on this c|net page:

https://www.cnet.com/news/google-chrome-to-block-autoplay-videos-from-january

-r


Note: Before finding out about this Issue, I posted a message "add preference to ask before loading and/or playing any video" to the Google Chrome Help Forum. After several interactions, requesting escalation of the question, and providing example URLs, I was informed that "This behavior is intended on Chrome.".  This seems to indicate that there is (at least) a communication issue inside Google...

Comment 48 by s6b...@gmail.com, Feb 24 2018

It is ridiculous that a side effect of some feature being added is allowing autoplay. As a countermeasure I've also tried chrome://flags/#autoplay-policy which stops Flash videos well from autostart.

Scroll 1/2 way down sfgate.com and you're immediately pummeled with video you don't care to see. 

Find the Product Manager, get them to sort this out. Giving users a choice is fine, hammering the user with things they don't want makes people leave an app.
Status: Fixed (was: Started)

Comment 50 by s6b...@gmail.com, May 14 2018

Awesome to see this fixed. Which release shall we see it available?
Labels: -M-65 M-66
Chrome 66

Comment 52 by s6b...@gmail.com, May 14 2018

Thanks -- for both desktop and mobile devices?
(Sorry should have asked that as well!)
Labels: -OS-All OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Yes :)

Comment 54 by t...@malcolmson.ca, May 14 2018

To clarify, I believe that this feature, which is often referred to simply as 'autoplay' both here and in the media, is actually just getting sites to mute their autoplay videos.

So it does nothing to address the larger problem of autoplay video ads consuming your cellular data plans and battery, etc.

For that, I think the only solution is still extensions.  And on mobile that means dumping Chrome for something like Firefox which supports extensions on mobile.
Would somebody mind either summarizing the preceding 50+ comments or pointing to a piece of user-facing documentation about how Chrome handles autoplay policy currently?  From c51 it sounds like the intended solution is in place in the release channel, but I can't find anything public about how it works or how I'm supposed to configure it (as a user), if that's possible. (If it's not currently possible to configure it, is there a separate issue for that?)
Basically, a "worst of both worlds" compromise was implemented. Video still autoplays, but is muted. If you want to watch it, you have to manually unmute it. If you don't, you have to manually pause it to stop it from being a bandwidth wasting distraction. This extension has been working for me, but the only solution on mobile is to use Firefox.

https://chrome.google.com/webstore/detail/autoplaystopper/ejddcgojdblidajhngkogefpkknnebdh
Yikes.  Well, good to know, I guess. I've been using https://github.com/Eloston/disable-html5-autoplay/ but wound up here because, when I went to suggest it to a friend, I discovered that it's now unmaintained -- ostensibly, because Chrome is going to fix the problem so an extension will be unnecessary.  It works well enough for me as-is, but maybe I'll place a comment on their tracker to the effect that Chrome's "solution" isn't enough.
Yeah, the short version is anything can autoplay as long as it is muted. Whether it can start with audio or not is a calculated signal inside your individual chrome install (based on whether you've interacted with that origin's stuff previously). Interactivity history (eg: youtube) gets audio at load, while no history of interaction will in general result in muted videos playing.
Trying to be smart about allowing it based on previous interactions is all fine and dandy but the reality is that most of the people complaining on this issue just want a knob to turn it off.

What is so hard to understand that many of us want to be able to not have any autoplay whatsoever?  Especially on mobile where I literally never have sound on while browsing and video drains my data and battery.
That is very clear and they certainly understand it by now. Our feedback was received but they don't want to do it, likely to protect advertising or business relationships. Unfortunately Firefox is taking a similar approach with muted video. 

These companies are not interested in user feedback when it runs contrary to their business goals. Why would they be?

Of course both Chromium and Firefox are open-source so they could be forked. But that's such a huge job that nobody's willing to do it.
There's already an interface for granting permissions per site, used for things like local storage and Flash playback. No reason why Autoplay behavior couldn't be there as well.

Until they see sense, I guess we're stuck with extensions. At least that way, I have total control over how media behaves.
The thing about silent videos is that they are often taking the place of
animated GIFs, where I suppose APNG would be unnecessarily large. So
playing those is probably something you want... Probably. But as for those
with audio, I could definitely understand wanting some manual control over
them. Heck, I use a user script to keep YouTube from auto playing, among
other things.

Sign in to add a comment