1420389 - (autoplay-UX-spec) UX spec for autoplay policy

Status: RESOLVED FIXED

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

Description

[Alastor Wu [:alwu]]

This bug is used for UX spec discussion.

Comment 1

[Ralph Corderoy]

I've arrived from bug 1231886 as I'd like to point out that worldwide, there's probably quite a few Firefox users like me;  ones that pay monthly for their ADSL broadband connection and that gives them a f​ixed number of bytes they can transfer, e.g. 10 GiB.  If that is used up before the month end then extra bytes are prohibitively expensive in comparison.

This means it's vital not to have a couple of videos, even if silent, autoplaying at the bottom of a web page, out of view, in a tab I haven't switched to yet.  And even when I do switch to it, that might be in passing with Ctrl-Tab to the one beyond it so they still shouldn't play.  If I scroll the page a bit, or interact with it to click `Cookies are OK' banner at the top that many European sites have due to legislation so it disappears, the videos still shouldn't autoplay.

Put simply, a video should never autoplay.  I should have to click its Play button.

Comment 2

[Alexander]

I would ask for a list of media that user can choose from to enable/disable. e.g.
* I have disabled autoplay
* I visit a website that I want some media to play but it doesn't
* I click in upper left corner to see list of blocked media and enable some of them

This is removing most of the guessing on browser side thus should make implementation simpler while maintaining full playability.

Comment 3

[crxssi]

(In reply to Alexander from comment #2)
> I would ask for a list of media that user can choose from to enable/disable.
> e.g.
> * I have disabled autoplay
> * I visit a website that I want some media to play but it doesn't
> * I click in upper left corner to see list of blocked media and enable some
> of them
> 
> This is removing most of the guessing on browser side thus should make
> implementation simpler while maintaining full playability.

Another option might be for Firefox to displays a media blocked icon- perhaps on the tab, because it saw media and blocked it (video or audio or both) and clicking on that icon tells the user what happened and gives the user the choice of enabling play for that page only (not for followed links, even on the same site) or enable for entire site, or enable for all sites.  Personally, I like you idea of a list of media being blocked, but the problem is a list is complicated.  I bet the typical user wouldn't understand a list...  What would you name each item in the list when there are several and how does the user know which one relates to which one on the page?

Like others, I think it is paramount that we have an effective way of blocking ALL autoplaying media.  I don't think allowing video to autoplay in a muted fashion is a good solution.  It still eats [potentially tons of] bandwidth, uses power (cpu and battery), and is still severely annoying/distracting if I didn't ask for it to play.  The last reason being MY main complaint with unrequested video- I simply cannot read or concentrate on any other part of a website page when there is any type of video or animation present.

Comment 4

[Damian Yerrick]

The spec author would need to keep in mind ways of autoplaying a short silent video without <video>, GIF, or even script. CSS sprite animation alone is enough for a motion JPEG player so long as the frame count times the width or height doesn't exceed 65535 pixels. Proofs of concept:

https://pineight.com/cssdemos/motionjpeg/mjpeg-css.html
http://blog.teamtreehouse.com/css-sprite-sheet-animations-steps

Comment 5

[Bryant Mao [:bryantmao]]

Here is the WIP autoplay spec for reference: https://mozilla.invisionapp.com/share/N2MD6ZV8CMG

Comment 6

[crxssi]

(In reply to Bryant Mao [:bryantmao] from comment #5)
> Here is the WIP autoplay spec for reference:
> https://mozilla.invisionapp.com/share/N2MD6ZV8CMG

Thanks again for the info.

[I must say, that is the most annoying set of pages, ever.  It is too wide for the window, has no way to adjust for window size, has no visible controls, and doesn't allow copying.  I know it is not related to this bug, but damn, what a horrible experience.]

That aside, here is the answer many might seek:  It is utterly broken and will apparently remain that way.  All that design and code work boils down to:  Firefox *will* allow autoplay if the video is muted, regardless what the user wants.  So it is NOT blocking autoplay, it ONLY has options to block unmuted video.  It looks like they went OUT OF THEIR WAY, to NOT allow the user to block all autoplaying content!  I am extremely disappointed, and I will not be alone.

Comment 7

[Alastor Wu [:alwu]]

(In reply to crxssi from comment #6)
> (In reply to Bryant Mao [:bryantmao] from comment #5)
> > Here is the WIP autoplay spec for reference:
> > https://mozilla.invisionapp.com/share/N2MD6ZV8CMG
> 
> Thanks again for the info.
> 
> [I must say, that is the most annoying set of pages, ever.  It is too wide
> for the window, has no way to adjust for window size, has no visible
> controls, and doesn't allow copying.  I know it is not related to this bug,
> but damn, what a horrible experience.]
> 
> That aside, here is the answer many might seek:  It is utterly broken and
> will apparently remain that way.  All that design and code work boils down
> to:  Firefox *will* allow autoplay if the video is muted, regardless what
> the user wants.  So it is NOT blocking autoplay, it ONLY has options to
> block unmuted video.  It looks like they went OUT OF THEIR WAY, to NOT allow
> the user to block all autoplaying content!  I am extremely disappointed, and
> I will not be alone.

If you want to use the old block autoplay mechanism which is only allowing autoplay when user clicks the element and not allow muted media to autoplay, you can still use it in Fx63 by changing the following pref.

> media.autoplay.default=1
> media.autoplay.enabled.user-gestures-needed=false

However, this old block autoplay mechanism is still not working for some websites (bug1231886) and it can't be fixed until the bug1185052 is fixed.

Comment 8

[Alastor Wu [:alwu]]

Our UX spec has been finished, close this bug.

Comment 9

[Alastor Wu [:alwu]]

FYI, not sure it would be helpful or not, here is the bug for the old UX spec.

Comment 10

[chsiang]

Hi Dale,
The updated UX specs was added to the link.

Comment 12

[Dale Harvey (:daleharvey)]

Clearing needinfo, picking up implementation in https://bugzilla.mozilla.org/show_bug.cgi?id=1517526

Comment 13

[Alastor Wu [:alwu]]

I think both of them have known this bug, so remove the NIs.

Comment 14

[Alastor Wu [:alwu]]

We have finished this long time ago, close this bug.