On Wednesday, July 4, 2018 at 11:38:21 AM UTC+12, Chris Pearce wrote: > Intent to ship: block audible autoplay media intervention > > 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 > > > Tracking bug: (block-autoplay) > https://bugzilla.mozilla.org/show_bug.cgi?id=1376321 > > > If you find bugs, please file them via this link and CC or need-info me > (cpearce), and mark them blocking bug 1376321: > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Audio%2FVideo%3A%20Playback > > > I will follow up with a confirmed ship date for block audible autoplay in > Firefox once we have one. > > > > [1] https://developers.google.com/web/updates/2017/09/autoplay-policy-changes > [2] https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/
Block autoplay is now enabled by default in Nightly (only). If you find bugs, please file them in "Core > Audio/Video > Playback" or via this link https://mzl.la/2JHYjlF and CC or need-info me (cpearce), and mark them blocking bug 1376321. If you have any feedback on whether you find the feature good, bad, or ugly, please email/IRC me, or let the team know in the block_autoplay Mozilla slack channel. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform