Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 33 users
Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 714676
issue 729518

Blocking:
issue 715051
issue 721707
issue 714156


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
Implement Unified Autoplay policy
Project Member Reported by mlamouri@chromium.org, Apr 25 Back to list
Blocking: 715051
Blocking: 714156
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: 721707
Project Member Comment 6 by bugdroid1@chromium.org, May 31
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
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
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

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


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 - 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.
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.
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.
Comment 26 by cdg...@gmail.com, Aug 17 (5 days ago)
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 (5 days ago)
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 (5 days ago)
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.
Comment 29 by orangewi...@gmail.com, Aug 17 (4 days ago)
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 (3 days ago)
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.

Sign in to add a comment