1517526 - Block autoplay behavior in control center

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect, P2)

Description

[chsiang]

This is to track block autoplay behavior in control center including two components:
- block autoplay icon behavior
- a way to easily add a site to the whitelist

Comment 1

[Eric Pang [:epang] UX]

Flagging Jacqueline on this as well so we are both aware of the bug.

Comment 2

[Jacqueline Savory [:jsavory] UX]

Adding the spec which describes the control center behaviour:
https://mozilla.invisionapp.com/share/Z7PXFBYYU6W#/340371394_Open_Control_Center

Comment 4

[chsiang]

reopen to use this bug to discuss control center behavior and track implementation.

Comment 5

[Dale Harvey (:daleharvey)]

Yup will take this one

Comment 6

[crxssi]

FYI for anyone finding this report....

From bug1420389, the UI still doesn't allow blocking of autoplay when muted (without sound). It only allows blocking of autoplay when unmuted (with sound). So many annoying videos will still play (just silently). The latest UI option (in control center and in preferences) is just toggling media.autoplay.allow-muted. Alastor Wu explained that the reason it doesn't [yet] is because they are waiting on bug1185052. He added that users can still use about:config to block ALL autoplay, although it might not be compatible with all sites.

That is what I am still doing/using, and generally it works fine (and I hope Mozilla doesn't try to remove it):

media.autoplay.default=1

Also make sure to use the UI to turn off media with sound OR use:

media.autoplay.allow-muted=false

and perhaps also:

media.autoplay.enabled.user-gestures-needed=false

See https://support.mozilla.org/en-US/questions/1238033 for more info.

I am not sure if the scope of THIS bug report includes the above, or if it should be in yet another bug... I apologize if this seems spammy, just trying to help people who are affected by it (like me) and really want to see an option for blocking muted video in preferences and the control center (in addition to about:config). :)

Comment 7

[Damian Yerrick]

Let me hazard a guess as to why Firefox has followed Google Chrome in allowing muted autoplay. If a user blocks autoplay of VP9, VP8, and AVC video even if muted, a site might fall back to a GIF animation, which has 10 times the file size for the same quality. If a user blocks autoplay of VP9, VP8, and AVC video and GIF animations, a site might fall back to use of JavaScript or even a pure CSS filmstrip.

So I'm interested in what method you propose to block all examples in this test suite:
https://pineight.com/cssdemos/autoplay-methods/

Comment 8

[crxssi]

(In reply to Damian Yerrick from comment #7)

Let me hazard a guess as to why Firefox has followed Google Chrome in allowing muted autoplay. If a user blocks autoplay of VP9, VP8, and AVC video even if muted, a site might fall back to a GIF animation, which has 10 times the file size for the same quality. If a user blocks autoplay of VP9, VP8, and AVC video and GIF animations, a site might fall back to use of JavaScript or even a pure CSS filmstrip.

Perhaps. Although you can block animated GIF by using the image.animation_mode setting in Firefox. It might still load it, but not play it (if you have it set to = none). You are correct that it could be an arms race on this type of stuff. But users need to be in full control of when and if video or sound is played and when.

I suspect the main reason Google did not allow full blocking (of muted video) is likely because Google is an advertising company and it is not in their best (selfish) interest to do such things. Mozilla/Firefox can and should be/do better than Google/Chrome.

http://kb.mozillazine.org/Animated_images_in_RSS_feeds_%28Thunderbird%29

"So I'm interested in what method you propose to block all examples in this test suite:
https://pineight.com/cssdemos/autoplay-methods/"

That kinda goes outside the scope of this particular bug report, but the most popular use- VP8, VP9, AVC, etc html5 video would all be blocked by media.autoplay.default. Animated GIF and PNG by image.animation_mode (although that is not selective). The remainder are all inefficient flip animations (filmstrips and such) using javascript and those would be a problem... but also very rare and if part of ads would be stopped with adblockers. I have to believe that 99.9+% of web sites would not stoop to that level of hostility, but who knows. If it got to that level, there could be counter measures that detect those types of animation javascripts and blocked (sounds like a great API hook-in opportunity for an addon).

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Cindy requested we track and coordinate landing this fix in Nightly66, currently it is planned to land on Monday Jan 21st.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Sounds fine; you don't have to request uplift or anything if this lands next week.
I would only worry if you ended up with string changes after next week.

Let's also make sure that QA will verify the changes show up and behave correctly according to the spec.

Comment 11

[chsiang]

Hi Liz, Flod,
We are considering to shorten the string. Is it correct to say that for any string changes, they should land no later than 1/25?

Comment 12

[Francesco Lodolo [:flod]]

(In reply to chsiang from comment #11)

Hi Liz, Flod,
We are considering to shorten the string. Is it correct to say that for any string changes, they should land no later than 1/25?

That sounds about right, if you want to make Monday's merge day. You could still request an uplift to Beta later, but I'd really prefer to avoid that, and target landing in mozilla-central.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Landing by the 25th should be fine.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

We should also add a release note. Cindy and team, do you have suggestions for wording for a release note, or anything to point to in documentation? We could ask for a writeup in SUMO for example, or your team could write a blog post.

Comment 15

[chsiang]

Hi Liz,
I put together a release note here.
https://docs.google.com/document/d/1TvZ7BIY2U2XIeCcXlnFjviv43cVAxxeupmMaSD1q_rw/edit?usp=sharing

Comment 16

[crxssi]

(In reply to chsiang from comment #15)

Hi Liz,
I put together a release note here.
https://docs.google.com/document/d/1TvZ7BIY2U2XIeCcXlnFjviv43cVAxxeupmMaSD1q_rw/edit?usp=sharing

Just an FYI- document is not viewable without a Google account. Some people don't want an account or want Google to track everything they do (and now Google will not allow people to create anonymous accounts because they are forcing account verification through phone numbers).

Comment 17

[Dale Harvey (:daleharvey)]

Attachment: https://phabricator.services.mozilla.com/D17130

Not sure phabricator is flagging reviews, or that anyone can see them

This change was so when the user is notified that an autoplay video is blocked (due to the global default of them being blocked) they could add the current url to the exceptions list straight from the control center to allow that site to autoplay

One issue I did consider was it may make sense for when the user picks "block" from the drop down and the default is block, it should remove the exception instead of adding a block one, however I figured that may be confusing and if we do want to change that behaviour it may be better as a follow up.

I had to change .value to .getAttribute("value") because .value seems to be lazy loaded due to it being a XBL property inside menulist and was undefined for an indeterminate period of time.

QA would have liked this to be landed yesterday so if you get a chance to look asap would be appreciated, cheers

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/92b46ae62036
Let user allow blocked autoplay. r=johannh

Comment 19

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/92b46ae62036

Comment 20

[Daniel Bodea [:danibodea]]

Where can I find the specs to verify the implementation of this bug?

Comment 21

[Dale Harvey (:daleharvey)]

Hey Bodea, The spec is @ https://bugzilla.mozilla.org/show_bug.cgi?id=1517526#c2, cheers

Comment 22

[Brindusa Tot, Desktop QA]

This bug was verified with the feature testing in Fx 66.