1376321 - (block-autoplay) [meta] blocking autoplay meta bug [***see URL link for more details***]

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, enhancement, P3)

Description

[Blake Wu [:bwu][:blakewu]]

This is a meta bug to track all the bugs related to media.autoplay.enabled=false. 
I have seen many bugs related to this and will set many bugs depend on this.

Comment 1

[Bill Gianopoulos [:WG9s]]

Fixing subject as it does not seem to describe what is being tracked here.

Comment 2

[Alastor Wu [:alwu]]

UX brief
https://docs.google.com/document/d/1VvJNMasDQu05ayAlkUrW6mkJT4f-JOd2iB75aFRBG0M/edit

UX questionnaire
https://docs.google.com/document/d/1xhXcnIKCUdEzYWHAXPaYkgbyBDvRcKRrLDybqNovwgA/edit#heading=h.a4221c9xjz82

Comment 3

[Alastor Wu [:alwu]]

Google blocking autoplay project
https://sites.google.com/a/chromium.org/dev/audio-video/autoplay

Comment 4

[Alastor Wu [:alwu]]

Google's document about "Unified Autoplay"
https://docs.google.com/document/d/1EH7qZatVnTXsBGvQc_53R97Z0xqm6zRblKg3eVmNp30/edit#

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: HTMLMediaElement.play() block autoplay logic

Current design for the logic of HTMLMediaElement.play() when block-autoplay is enabled.

Comment 7

[Eric Shepherd [:sheppy]]

For the writing team when the time comes, from the intent-to-ship message:

SUMMARY:

We intend to change the behaviour of HTMLMediaElement to block autoplay of audible audio and video in Firefox on desktop and mobile.

We are not going to block WebAudio at the same time. While we do plan to block audible autoplay of WebAudio content in the near future, we have not finalized our WebAudio blocking logic or intended ship date for blocking WebAudio.


TIMELINE:

We intend to run shield studies on the user impact of enabling HTMLMediaElement autoplay blocking. If those go well we hope to ship in Firefox 63 (2018-10-23) or Firefox 64 (2018-12-11). Upon conclusion of our experiments, I’ll follow up here with a confirmed ship date for this feature.

We hope to block autoplay in WebAudio in a release soon after, hopefully Firefox 64 or 65.


DETAILS:

We intend to block autoplay of HTMLMediaElement in tabs which haven't had user interaction. Web authors should assume that they require a user gesture (mouse click on a "play" button for example) in order to play audible media.

HTMLMediaElements with a "muted" attribute or "volume=0" are still allowed to play.

As with other browsers implementing this feature, we express playback being blocked by rejecting the promise returned by HTMLMediaElement.play(). Web authors should always check whether the promise returned by HTMLMediaElement.play() is rejected, and handle that case accordingly.

We also plan to allow users to create their own whitelist of sites which they trust to autoplay.

We are planning to experiment via shield studies with prompting users to approve/block playback on sites that try to autoplay before receiving user interaction.


ADVICE FOR WEB AUTHORS:

In general, the advice that applies to other browsers [1][2] with respect to autoplaying media will apply to Firefox as well; you cannot assume that you can just call HTMLMediaElement.play() for audible media and expect it to always play. You should always check whether the play promise is rejected, and handle that case accordingly.

For example:

var promise = document.querySelector('video').play();

if (promise !== undefined) {
    promise.catch(error => {
        // Auto-play was prevented
        // Show a UI element to let the user manually start playback
    }).then(() => {
        // Auto-play started
    });
}

(This example comes from WebKit’s announcement on blocking autoplay [2])

To test block autoplay in Firefox 63 (currently in Firefox Nightly channel), download the latest Nightly and open about:config in the URL bar and set the preferences:

media.autoplay.enabled=false
media.autoplay.enabled.user-gestures-needed=true
media.autoplay.ask-permission=true

Comment 9

[Torsten Villnow]

I have a problem with "media.autoplay.default":

If set to 1, then the following video (as a sample, I hav seen this elsewhere) can't be manually started:
https://www.msnbc.com/all-in/watch/fbi-opened-inquiry-into-whether-trump-working-for-russia-report-1424588867508

Comment 10

[Alastor Wu [:alwu]]

(In reply to Torsten Villnow from comment #9)

I have a problem with "media.autoplay.default":

If set to 1, then the following video (as a sample, I hav seen this elsewhere) can't be manually started:
https://www.msnbc.com/all-in/watch/fbi-opened-inquiry-into-whether-trump-working-for-russia-report-1424588867508H

Hi, Torsten,

Could you check whether you also have the pref "media.autoplay.enabled.user-gestures-needed=true"? I tested this site in the latest Nightly, it can start playing without problems.

Thank you.

Comment 11

[Torsten Villnow]

Hi Alastor,

"media.autoplay.enabled.user-gestures-needed" was set to false. After having changed it to true the videos on MSNBC can be manually started now. However, as a side-effect the videos on Youtube are now started automatically, which was not the case before this change. Is this working as intended with these settings?

Comment 12

[Alastor Wu [:alwu]]

(In reply to Torsten Villnow from comment #11)

Hi Alastor,

"media.autoplay.enabled.user-gestures-needed" was set to false. After having changed it to true the videos on MSNBC can be manually started now. However, as a side-effect the videos on Youtube are now started automatically, which was not the case before this change. Is this working as intended with these settings?

That is a known issue, if you disable "media.autoplay.enabled.user-gestures-needed", then it would break those webistes who are calling video.play() asynchronous in the user-event handler. That issue is blocked by bug1185052, so we're still waiting fot the fix. To only allow autoplay by user clicking, we call this model as click-to-play model, and as you see, it still can't work for every sites, so that is the reason why we don't enable this pref as a default option.

When you turn on the pref "media.autoplay.enabled.user-gestures-needed", video won't be allowed in the beginning, it would be allowed to autoplay after user activates page by user gesture (eg. mouse click, keyboard press, touch). We call this model as user-gesture-activation model. So Youtube would be allowed to autoplay after you activate them.

Comment 13

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

Suggested release note for block autoplay (from chsiang):

Block autoplay media: Firefox now blocks all autoplay media with sound by default. Users can add individual sites to an exceptions list or turn the blocking off. Visit our support page to learn how to do that. We recommend websites to follow these strategies to avoid media been blocked and to provide the best user experience.

Comment 14

[MarjaE]

Depends on: 1642250

Comment 15

[t28427]

I've explicitly blocked audio and video on Yahoo Finance and it starts playing when I cycle tabs back and forth into the page. I've been reading a bunch of the related bugs and my understanding is that setting to "block audio and video" should not allow this.
It sometimes doesn't play at first but it triggers soon after and resumes play as soon as I open the tab again. This is CPU intensive more than any other thing, which slows down the rest of the browser.

Upon un-muting the video, it behaves correctly and no longer starts playing when I go back to the page to check on new data.

Comment 16

[Alastor Wu [:alwu]]

(In reply to t28427 from comment #15)

I've explicitly blocked audio and video on Yahoo Finance and it starts playing when I cycle tabs back and forth into the page. I've been reading a bunch of the related bugs and my understanding is that setting to "block audio and video" should not allow this.
It sometimes doesn't play at first but it triggers soon after and resumes play as soon as I open the tab again. This is CPU intensive more than any other thing, which slows down the rest of the browser.

Upon un-muting the video, it behaves correctly and no longer starts playing when I go back to the page to check on new data.

Could you try other blocking autoplay policies [1] to see if any of them work for you? That document also describes what media we would block under different policies.

[1] https://docs.google.com/document/d/1p81bYntlLMTxXoANnQXS9KH0TZ4y8aKKeH9x3GVS3eY/edit#heading=h.k7kwgndce3xw

Comment 17

[Alastor Wu [:alwu]]

In addition, we have finished developing this feature already, I will close this bug, but will still use this bug to track any related issues.