Revert the removal of an option to block autoplay from Chrome

[baybal]

Is your feature request related to privacy?

Yes

Is there a patch available for this feature somewhere?

No, but I believe a quick search in chromium git will avail for a quick undoing of the change.

JS based solutions are available https://github.com/Eloston/disable-html5-autoplay

Describe the solution you would like

Revert to autoplay blocking the way it was done in chrome 7x.x, where autoplay block was blocking all videos.

Android Chrome 82.x+ will still play videos even if they are autoplay blocked if they pass some obscure "engagement score:" https://www.theregister.com/2020/09/08/google_chrome_autoplay/

Describe alternatives you have considered

Reverting to older versions works

[baybal]

Removals in commit history:

chromium/chromium@1785f13
chromium/chromium@f286512

[csagan5]

Those commits are about "muted autoplay", not autoplay as a whole. We need to look deeper into how and why this was changed.

Related: https://www.theregister.com/2020/09/08/google_chrome_autoplay/

[uazo]

Removals in commit history:

I think he's right, the only real change is here,

chromium/chromium@f286512#diff-817bdb7b9f231d251a99cdb41048f4b4592efa614697f02b532c88bfc30aa3edL313

everything else is for options (and bringing them to the rendering process), as well as for testing.
to re-enable the old behavior for all sites, seems it's enough

return true; // !(IsEligibleForAutoplayMuted();

i tried and it seems autoplay is off (tested with youtube and reloading page, the goal is perhaps to block all videos making user gesture mandatory?).
Can someone provide some other test cases?

[csagan5]

Ok, so the commits mention "muted autoplay" but they are actually removing access to all of the autoplay settings.

@uazo what I think we should restore is also the Media site settings which contained the option to enable/disable autoplay

[uazo]

yes, but maybe we should wait for the refactoring of the content settings code (by the chromium team) to finish.
for now I suggest to change only that line.

[csagan5]

Do you have an issue link for that refactoring? I am not aware.

[uazo]

you're right, It's not a refactoring, but a revert of a revert! next time I research before writing wrong things.

https://chromium-review.googlesource.com/c/chromium/src/+/2247730
https://chromium-review.googlesource.com/c/chromium/src/+/2249282
https://chromium-review.googlesource.com/c/chromium/src/+/2240413

if you agree I'll try to restore that option.

[csagan5]

https://chromium-review.googlesource.com/c/chromium/src/+/2247730
https://chromium-review.googlesource.com/c/chromium/src/+/2249282
https://chromium-review.googlesource.com/c/chromium/src/+/2240413

This seems to be a replacement for PrefServiceBridge, it does not seem a big change.

if you agree I'll try to restore that option.

We should get back the Media site setting to toggle autoplay, is that what you mean?

[uazo]

We should get back the Media site setting to toggle autoplay, is that what you mean?

yes, we can try to make a revert of #791 (comment)

[csagan5]

@uazo yes, that would be great

[uazo]

@csagan5 at what point of the bromite-patch list would you like the new patch?

[csagan5]

@uazo you can always append them; I will put them before the automated domain substitution before release.

[buawf]

Removals in commit history:

I think he's right, the only real change is here,

chromium/chromium@f286512#diff-817bdb7b9f231d251a99cdb41048f4b4592efa614697f02b532c88bfc30aa3edL313

everything else is for options (and bringing them to the rendering process), as well as for testing.

i tried and it seems autoplay is off (tested with youtube and reloading page, the goal is perhaps to block all videos making user gesture mandatory?).

@uazo Can it be possible to block autoplay for twitter videos &/or Gifs ?

[csagan5]

@uazo Can it be possible to block autoplay for twitter videos &/or Gifs ?

@buawf we are restoring a pre-existing functionality, if gifs were not blocked before they will not be now

[csagan5]

@uazo there is also in the code something called UnifiedAutoplayConfig and a setting kBlockAutoplayEnabled

In the commit chromium/chromium@0403932 it says:

We should also use the autoplay policy from WebPreferences.

So this is independent from the other one, somehow. And it is more focused on sound. Can you look into UnifiedAutoplayConfig and kBlockAutoplayEnabled to see if it is worth enabling them as well for Android and disabling any smart machinery that they might have put there?

[uazo]

@uazo Can it be possible to block autoplay for twitter videos &/or Gifs ?

@buawf we are restoring a pre-existing functionality, if gifs were not blocked before they will not be now

Yes, it's no.
anyhow @buawf can you provide some urls to test?

[buawf]

anyhow @buawf can you provide some urls to test?

https://www.twitter.com/UniverseIce/status/1324993628071108608

Edit:-
https://www.twitter.com/arter97/status/1325127957497573380

[uazo]

autoplay appears to be blocked.

[uazo]

So this is independent from the other one, somehow. And it is more focused on sound. Can you look into UnifiedAutoplayConfig and kBlockAutoplayEnabled to see if it is worth enabling them as well for Android and disabling any smart machinery that they might have put there?

Yes, seems related to sound context:

UnifiedAutoplayConfig 
Add a toggle to the sound content settings page to toggle
unified autoplay. Also adds a pref to store the user's
preference.

Used here:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/modules/webaudio/audio_context.cc;l=468

here some explanation (console warning):

 switch (GetAutoplayPolicy()) {
    case AutoplayPolicy::Type::kNoUserGestureRequired:
      NOTREACHED();
      break;
    case AutoplayPolicy::Type::kUserGestureRequired:
      DCHECK(window->GetFrame());
      DCHECK(window->GetFrame()->IsCrossOriginToMainFrame());
      window->AddConsoleMessage(MakeGarbageCollected<ConsoleMessage>(
          mojom::ConsoleMessageSource::kOther,
          mojom::ConsoleMessageLevel::kWarning,
          "The AudioContext was not allowed to start. It must be resumed (or "
          "created) from a user gesture event handler. https://goo.gl/7K7WLu"));
      break;
    case AutoplayPolicy::Type::kDocumentUserActivationRequired:
      window->AddConsoleMessage(MakeGarbageCollected<ConsoleMessage>(
          mojom::ConsoleMessageSource::kOther,
          mojom::ConsoleMessageLevel::kWarning,
          "The AudioContext was not allowed to start. It must be resumed (or "
          "created) after a user gesture on the page. https://goo.gl/7K7WLu"));
      break;
  }

Testing with https://uazo.github.io/bromite/autoplay.html I've the following error:
DOMException: play() failed because the user didn't interact with the document first. https://goo.gl.qjz9zk/xX8pDD

(source https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/media/autoplay_policy.cc;l=318)
so, by default GetAutoplayPolicy() is AutoplayPolicy::Type::kDocumentUserActivationRequired

seems fine, right?

[csagan5]

Fixed in 86.0.4240.194.

[csagan5]

seems fine, right?

It depends. This is the enum:

  // Different autoplay policy types.
  enum class Type {
    kNoUserGestureRequired = 0,
    // A local user gesture on the element is required.
    kUserGestureRequired,
    // The document needs to have received a user activation or received one
    // before navigating.
    kDocumentUserActivationRequired,
  };

Is kDocumentUserActivationRequired more strict than kUserGestureRequired or less strict? I think it is less strict.

[uazo]

I think it is less strict.

Yes sure. but "The document needs to have received a user activation" is the same behavior we did for autoplay videos (and at that point we should think about modifying that too).
also currently we do not know how many sites we would break with that change, consider that the videos show something to users (which can receive activation), the audiocontext may have no ui.
If it were contentsettings you might think about exceptions, but that's a command line switch and turning it into that would require several changes.
personally I would wait.
Alternatively I would think of a substantial modification of the content settings ui, faster to integrate and maintain, using object-oriented programming instead of that if-else chain of the mists of time (so as to be able to insert also other perhaps more interesting changes, like selective history)

[csagan5]

"The document needs to have received a user activation" is the same behavior we did for autoplay videos (and at that point we should think about modifying that too).

No, videos in Bromite need the play button to be clicked. That does not correspond to "document needs to have received a user activation" but rather to "a local user gesture on the element is required."

Unless I am missing something here?

the audiocontext may have no ui.

Then it will not play. What % of sites have audio without controls? I think it is a minority to ignore.

that's a command line switch and turning it into that would require several changes.

It is very easy to convert it to a flag, if there is not already one.

Alternatively I would think of a substantial modification of the content settings ui, faster to integrate and maintain, using object-oriented programming instead of that if-else chain of the mists of time (so as to be able to insert also other perhaps more interesting changes, like selective history)

The maintenance of a rewritten content settings UI would take considerable effort over time, no? Would you commit to this type of maintenance? The current version still requires less maintenance than a rewrite.

What do you mean by selective history? Storing history only for certain websites? Sounds interesting.

[uazo]

videos in Bromite need the play button to be clicked.

I might be wrong, I do not think so. tomorrow I check the code but try to open a video on youtube and click on the privacy popup, the video starts and you did not click on it.

I think it is a minority to ignore.

otherwise they will just come back as bug reports (as it has already happened)

I refer to what you said (and that I agree with you), if there is a user who can complain it is necessary to foresee it.

It is very easy to convert it to a flag, if there is not already one.

I meant a content setting, so we can activate the ability to exclude broken sites

The maintenance of a rewritten content settings UI would take considerable effort over time, no?

I don't know, we should try.

Would you commit to this type of maintenance?

Of course.

The current version still requires less maintenance than a rewrite.

I trust you, you have more experience, but I would like to try, let's see if I convince you, just have patience, I'd like to finish other things first

What do you mean by selective history? Storing history only for certain websites? Sounds interesting.

yes, just that.

[csagan5]

I refer to what you said (and that I agree with you), if there is a user who can complain it is necessary to foresee it.

In this case they can change the flag and restore the audio autoplay. In that case it was different, our UI change was not giving the user any option to get back the upstream behaviour.

I might be wrong, I do not think so. tomorrow I check the code but try to open a video on youtube and click on the privacy popup, the video starts and you did not click on it.

Try with Vimeo and others as well.

I will open a new issue (#804) since this one is already fixed.

[nikolowry]

@csagan5 @uazo two issues with this, one being a bug and the other is an opinion.

Bug
The global "Autoplay" site-setting is broken and cannot be toggled on in Settings > Site Settings > Autoplay. I'm only able to enable on a site-by-site basis. Screen capture from Pixel 5 running Android 11: https://neeks.me/cloud/index.php/s/S7iNof4e93da6Np (MP4 too large to upload here)

Opinion
As a full-stack web developer that specializes in frontend UI/UX, it really disappointed me to see muted videos blocked by default.

For the past few years, there's been a growing trend of to use "video wallpapers". Here's my employer's site with a "video wallpaper" for reference: https://brooklynfoundry.com. From a browsing experience, I don't mind these "video wallpapers" because they act as a design element -- but I loathe sites (e.g news sites) that have a fixed player and block the screen.

Prior to iOS 10, this "video wallpaper" pattern was seldom used when a mobile device was detected. But once Google and Webkit's autoplay policies became aligned in 2016, we started implementing these more and more. I'm not a fan of them on devices that are only using mobile-data (it's inconsiderate to waste non-unlimited users money for "design"), but I'm not the one calling those types of shots.

[uazo]

one being a bug

thanks for reporting, I had not noticed!

it really disappointed me to see muted videos blocked by default

you can see it from another point of view: if it is a choice of the user, it must be respected, also thinking that autoplay may be an accessibility issue for people with disabilities.
a webdesigner can ask for permission if necessary .. I personally think so.

[csagan5]

I see it no different than the permission for microphone access; in Bromite we are simply going to ignore the "media engagement index" and let the user explicitly decide.

[nikolowry]

Thanks for the quick fix and replies @uazo @csagan5!

I totally agree about user choice as well. My previous rant was a result of my annoyance from the bug, if I could have enabled it once I wouldn't have been so fixated on what the default value was.