[meta] blocking autoplay meta bug [***see URL link for more details***]
Categories
(Core :: Audio/Video: Playback, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
relnote-firefox | --- | 66+ |
People
(Reporter: bwu, Unassigned)
References
(Depends on 16 open bugs, )
Details
(Keywords: dev-doc-needed, feature, meta, Whiteboard: use `media.autoplay.blocking_policy` to select different blocking autoplay policy)
Attachments
(1 file)
383.31 KB,
image/jpeg
|
Details |
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.
Reporter | ||
Updated•7 years ago
|
Comment 1•7 years ago
|
||
Fixing subject as it does not seem to describe what is being tracked here.
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment hidden (obsolete) |
Comment 3•7 years ago
|
||
Google blocking autoplay project https://sites.google.com/a/chromium.org/dev/audio-video/autoplay
Comment 4•6 years ago
|
||
Google's document about "Unified Autoplay" https://docs.google.com/document/d/1EH7qZatVnTXsBGvQc_53R97Z0xqm6zRblKg3eVmNp30/edit#
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 6•6 years ago
|
||
Current design for the logic of HTMLMediaElement.play() when block-autoplay is enabled.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 7•6 years ago
|
||
DDN-Comment |
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
Updated•6 years ago
|
Updated•6 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 14•4 years ago
|
||
Depends on: 1642250
Comment 15•3 years ago
|
||
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•3 years ago
|
||
(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.
Comment 17•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•