Intent to implement: Disabling auto-play videos on mobile networks/devices?

[Wesley Johnston]

Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay. We should be more mindful of users and try to avoid using data if they don't want it. Sites should be doing this for us, but we've encountered pages where that is not the case. I'm proposing that we at least disable this if the audio/video has to be pulled over a (paid?) mobile network. It may, because of the context that phones are used, be something we'd disable on mobile in general. i.e. The bug report mentions someone using their phone in a quiet setting at home. Theres also some power usage concerns that this would help with. The spec allows this explicitly "Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired". Sites (like games) that want to override this could still use scripting to autoplay (and probably already do).
Link to standard: http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-autoplay
Platform coverage: Where will this be available? Android, Firefox OS
Estimated or target release: Aiming for Firefox 35.
Preference behind which this will be implemented: Not sure. We already have a boolean media.autoplay.enabled. I think the best thing would probably be to make it a tri-state.pref.

[Nick Alexander]

Hi Wes,

On 2014-08-21, 10:29 AM, Wesley Johnston wrote:
> Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay. We should be more mindful of users and try to avoid using data if they don't want it. Sites should be doing this for us, but we've encountered pages where that is not the case. I'm proposing that we at least disable this if the audio/video has to be pulled over a (paid?) mobile network. It may, because of the context that phones are used, be something we'd disable on mobile in general. i.e. The bug report mentions someone using their phone in a quiet setting at home. Theres also some power usage concerns that this would help with. The spec allows this explicitly "Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired". Sites (like games) that want to override this could still use scripting to autoplay (and probably already do).

In general, I'm in favour of not autoplaying at all on mobile devices.

> Link to standard: http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-autoplay
> Platform coverage: Where will this be available? Android, Firefox OS
> Estimated or target release: Aiming for Firefox 35.
> Preference behind which this will be implemented: Not sure. We already have a boolean media.autoplay.enabled. I think the best thing would probably be to make it a tri-state.pref.

Why is it not sufficient to just set media.autoplay.enabled=false on
mobile platforms? (MXR suggests autoplay is enabled on all platforms.)
Is the concern that disabling autoplay too widely will lead to
widespread scripted-autoplay, reducing user control yet further?

Can you be explicit about the three states of this proposed tri-state pref?

Nick

[Wesley Johnston]

> In general, I'm in favour of not autoplaying at all on mobile devices.

I think I was just trying to address the spec's statement of overriding when not desired. I don't want to punish sites that are reading that and trying to be good citizens. For instance, <video> elements are actually a good solution if you want an animated background on a site, and provide good fallbacks when they're disabled. I want to at least discuss making a good faith effort to only disable it when necessary. But I won't argue that we can have a perfect heuristic for that either (I'm not sure how we know if you're in a library). Maybe "phone" is the best we can do for users. Maybe we need to discuss disabling audio (from audio or video elements) and video separately?

> Is the concern that disabling autoplay too widely will lead to widespread scripted-autoplay, reducing user control yet further?

My concern is that this may break sites without providing much feedback to them about why. I'd like to minimize bustage/confusion for developers, as well as doing our best to respect their requests.

> Can you be explicit about the three states of this proposed tri-state pref?

I was thinking something like:
Enabled - Always works
Disabled - Never works
Dynamic - Up to UA.

Technically, I'd be fine putting this behind Enabled, but if we want the dynamic behaviour behind a pref, it seemed simpler to add it here than to start dealing with combinatorials of different prefs.

[Jonas Sicking]

In general I think this sounds like a good idea. Not honoring autoplay
when on a mobile connection sounds good. I'm unsure what the best
behavior is on a mobile device when on a wifi connection, so I don't
feel strongly either way there.

On Thu, Aug 21, 2014 at 11:16 AM, Wesley Johnston <wjoh...@mozilla.com> wrote:
>> Can you be explicit about the three states of this proposed tri-state pref?
> I was thinking something like:
> Enabled - Always works
> Disabled - Never works
> Dynamic - Up to UA.

I don't understand this. We are the UA, so what does "dynamic"
actually mean? Making it a tristate for "always", "never" and "only on
wifi" would make sense to me if that's what you mean?

/ Jonas

[Dirkjan Ochtman]

On Thu, Aug 21, 2014 at 7:51 PM, Nick Alexander <nalex...@mozilla.com> wrote:
> In general, I'm in favour of not autoplaying at all on mobile devices.

Me too!

Anecdotal: recently I woke up my wife when I was trying to overcome
sleeplessness by browsing my phone a little bit (a questionable method
of doing so, but hey!) and I ran into some very loud ad that started
autoplaying (this was on my home Wifi).

Cheers,

Dirkjan

[Dao]

... which of course could also happen with a laptop ...

[Hubert Figuière]

On 21/08/14 01:29 PM, Wesley Johnston wrote:
> Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay.

Just on mobile?

I filed this a while ago.
https://bugzilla.mozilla.org/show_bug.cgi?id=980939

It doesn't seem to have gained traction until I saw this.

Autoplay is annoying
Autoplay waste bandwidth, whether mobile or wifi. In some case it is
more serious than other.
Autoplay disturb people.

Since it is possible it gets abused.

Etc.

Hub

[Jared Hirsch]

FWIW, Safari on iOS doesn't allow autoplay or preload, and also only initiates play/load on a user-triggered event (so, pages can't use JS to fake a click).

The reason given in the docs[1] is that users might be charged for that bandwidth.

Cheers,

Jared

[1] https://developer.apple.com/library/safari/documentation/audiovideo/conceptual/using_html5_audio_video/device-specificconsiderations/device-specificconsiderations.html

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Wesley Johnston]

For reference, our preload code on Android and B2G is also a bit complex. i.e. If the page doesn't say anything about what to preload, we preload nothing. If they ask for preload="auto" we default to only preload metadata.

- Wes

[Mike Hommey]

On Thu, Aug 21, 2014 at 10:29:43AM -0700, Wesley Johnston wrote:
> Summary: We've had some complaints at times about videos autoplaying
> on mobile devices

Note that laptops are both desktop and mobile devices. That is, someone
could very well using a desktop build on a device using a
mobile-carrier-backed network (either by tethering or directly).

Mike

[Jonas Sicking]

Indeed. Android-based wifi hotspots actually broadcast that they
provide a tethered mobile connection. So we could detect this and
provide the same treatment on desktop.

I filed this yesterday which is very related.

https://bugzilla.mozilla.org/show_bug.cgi?id=1057169

/ Jonas

[Robert O'Callahan]

On Sat, Aug 23, 2014 at 5:59 AM, Jared Hirsch <6a...@mozilla.com> wrote:

> FWIW, Safari on iOS doesn't allow autoplay or preload, and also only
> initiates play/load on a user-triggered event (so, pages can't use JS to
> fake a click).
>
> The reason given in the docs[1] is that users might be charged for that
> bandwidth.
>

Web developers hate that policy and do crazy things to try to get around
it. For example, in a game with sound effects instead of using individual
audio elements to play sounds, they put all the sounds in one file and when
the user clicks to start playing they start playing that file and seek
around in it to play an effect at a particular time. It's horrible.

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

[Eric Rescorla]

On Fri, Aug 22, 2014 at 9:12 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

> On Sat, Aug 23, 2014 at 5:59 AM, Jared Hirsch <6a...@mozilla.com> wrote:
>
> > FWIW, Safari on iOS doesn't allow autoplay or preload, and also only
> > initiates play/load on a user-triggered event (so, pages can't use JS to
> > fake a click).
> >
> > The reason given in the docs[1] is that users might be charged for that
> > bandwidth.
> >
>
> Web developers hate that policy and do crazy things to try to get around
> it. For example, in a game with sound effects instead of using individual
> audio elements to play sounds, they put all the sounds in one file and when
> the user clicks to start playing they start playing that file and seek
> around in it to play an effect at a particular time. It's horrible.

FWIW, to the best of my knowledge WebRTC calls do not require a click.

-Ekr

[Justin Dolske]

On 8/22/14 10:17 AM, Hubert Figui�re wrote:
> On 21/08/14 01:29 PM, Wesley Johnston wrote:
>> Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay.

[...]

> Autoplay waste bandwidth, whether mobile or wifi. In some case it is
> more serious than other.

I think it would make a lot of sense to have an explicit "low bandwidth
mode" that did stuff like this, instead of trying to address it
piecemeal. There's all kinds of stuff that can consume bandwidth, and if
we think it's a real concern then let's directly address it.

Consider the increasingly popular gfycat.com. It offers GIF hosting with
reduced bandwidth, by encoding as WebM. Example:

http://www.gfycat.com/SpectacularPerfectCygnet.html (910K WEBM)
http://giant.gfycat.com/SpectacularPerfectCygnet.gif (10.9MB GIF)

Autoplay makes complete sense in this context, just as every browser
will "autoplay" a GIF. If the concern is actually bandwidth, then it
would be better to avoid/abort loading video _and_ images above some
arbitrary threshold. Why penalize a 910K video file but not an images
12x as large? Should be the other way around!

Justin

[Jonas Sicking]

In practice most videos are larger than most gifs. Yes, there are
exceptions, and yes, there are other features that we could add to
further reduce bandwidth usage, but we shouldn't let perfect be the
enemy of good.

Especially given that autoplay was explicitly added in order for UAs
to implement policies such as the ones discussed here. It seems silly
of us not to take advantage of that.

If gfycat absolutely wants to autoplay their videos, they can still
use the .play() API. That's what the spec says to do.

That said, if you have ideas for how we can do even better, definitely
speak up. I'd be happy to stop downloading animated gifs over a
certain size over mobile connections if we can have some UI which lets
the user resume the download.

/ Jonas

[Daniel Veditz]

On 8/24/2014 6:21 PM, Eric Rescorla wrote:
> FWIW, to the best of my knowledge WebRTC calls do not require a click.

But you have to click on the door-hanger to share camera/mic (or be on a
site you have already trusted not to abuse the permissions).

-Dan Veditz

[Eric Rescorla]

That's for outgoing media. Incoming media works fine without any
permissions grant.

-Ekr


>

[Patrick McManus]

On Mon, Aug 25, 2014 at 3:03 AM, Justin Dolske <dol...@mozilla.com> wrote:

> I think it would make a lot of sense to have an explicit "low bandwidth
> mode" that did stuff like this, instead of trying to address it piecemeal.
> There's all kinds of stuff that can consume bandwidth, and if we think it's
> a real concern then let's directly address it.
>
>

I think that's a pretty cool idea - I'm on vacation for another week, can
you file a bug and cc: me? Or I'll do it when I come back.

There are a couple technical gotchas involved in that - basically to do it
effectively you need to open a connection with a small window (which is
fine).. if you want the connection to run faster you need to open the
window back up - and some msft OS's (actually maybe all of them) won't let
you open it past 64KB if you start with an intentionally small one and
that's not enough for full line rate on a lot of networks. But that should
be manageable for this use case.

[Zack Weinberg]

On 2014-08-25 1:04 PM, Jonas Sicking wrote:
>
> That said, if you have ideas for how we can do even better, definitely
> speak up. I'd be happy to stop downloading animated gifs over a
> certain size over mobile connections if we can have some UI which lets
> the user resume the download.

Seems to me there might be value in applying <video controls>-style
controls to animated <img>s *in general* -- not just for mobile.

[Nicholas Nethercote]

On Wed, Aug 27, 2014 at 5:49 AM, Zack Weinberg <za...@panix.com> wrote:
>
> Seems to me there might be value in applying <video controls>-style controls
> to animated <img>s *in general* -- not just for mobile.

That's a great idea!

Nick

[Zack Weinberg]

Looks like that's https://bugzilla.mozilla.org/show_bug.cgi?id=560084 .

[Justin Dolske]

On 8/26/14 6:43 AM, Patrick McManus wrote:

>> I think it would make a lot of sense to have an explicit "low bandwidth
>> mode" that did stuff like this, instead of trying to address it piecemeal.
>> There's all kinds of stuff that can consume bandwidth, and if we think it's
>> a real concern then let's directly address it.
>>
>>
> I think that's a pretty cool idea - I'm on vacation for another week, can
> you file a bug and cc: me? Or I'll do it when I come back.

This would be bug 859998.

Justin