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
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
