Should we disable "autoplay" feature of HTMLMediaElement on mobile?

[Tetsuharu OHZEKI]

Hi,

In Last week, I proposed the following mail to mobile-firefox-dev mailing list.
I feel this proposal is related to not only Fennec, but also B2G.

So I would like to hear your opinions.

Best Regards.

---------- Forwarded message ----------

Hello,

I propose that we should disable "autoplay" feature of
HTMLMediaElement on mobile.
(I'm sorry if this topics has been discussed for a long time ago in past times.)

At the current configuration, Gecko runs on mobile (Firefox for
Android, B2G) are enable the "autoplay" feature of HTMLMediaElement
with using `media.autoplay.enabled=true`.

However, I think this might not be useful for users. Because:
* Mobile Devices are more used in public space than Desktop PCs. If
browser auto-plays all media which come from web without some user
activations, this should be privacy risk.
* And, simply, it would shame me if browser auto-plays web page audio
in the silent public space.
* In related with above things, this behavior might have social attack
risk by web pages.
If browser auto-plays x-rated (violent, porn or etc) video/audio with
loud volumes in the public space, his user's name will be mud.

So I propose "we should disable "autoplay" feature of HTMLMediaElement
on mobile".
And I would like to discuss about it.

I welcome your feedback to polish Firefox for mobile and web.

Best Regards.

--
Tetsuharu OHZEKI
saneyuk...@gmail.com

[Robert O'Callahan]

Don't these arguments apply to desktop Firefox used at work, in an Internet
cafe, or in a library, as well?

I think it's important to have an easy way to mute/unmute the browser, but
disabling autoplay is probably not the right way to address these issues.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w

[Tetsuharu OHZEKI]

2013/12/8 Robert O'Callahan <rob...@ocallahan.org>:

> Don't these arguments apply to desktop Firefox used at work, in an Internet
> cafe, or in a library, as well?

True.
This proposal could be applied to desktop Firefox. But I seem it would
be hard because of historical reasons.
On today's web, there are many "interactive" web sites which play
sounds when open them. Some of them are not controlled by users
because they doesn't not provide any control. This is website's
problem for accessibility/usability. But I also think that this is a
user agent (browser)'s problem originally.
However, Sadly, It's too late to change the behavior now for desktop browser.

> I think it's important to have an easy way to mute/unmute the browser, but
> disabling autoplay is probably not the right way to address these issues.

Yes. I agree that disabling autoplay is not right way. For only
mobile, I think that the approach like click-to-play may be good to
resolve this issues. This "click-to-play" focuses only to absorb the
problem of autoplaying which includes privacy, honor, and traffic
attacks.

Although I think this might be resolved before mobile web expand more
and more. Now, B2G are very young platform. If we try to resolve these
issue, this moment would be chance to resolve it.


2013/12/8 Robert O'Callahan <rob...@ocallahan.org>:

--
Tetsuharu OHZEKI
saneyuk...@gmail.com

[Robert Kaiser]

Tetsuharu OHZEKI schrieb:

> I propose that we should disable "autoplay" feature of
> HTMLMediaElement on mobile.

I personally have not yet seen any arguments that would really apply for
making things different between mobile and desktop in your discussion,
and I think we should not make functionality different between form
factors or products when there is no good reason to make them different.
IMHO, what's named "Firefox" should work the same everywhere unless
there is a really good reason why a different variant should behave
differently (and there surely are often good reasons, but I haven't
noticed those in this discussion yet - nobody says I won't often use my
laptop in public or my mobile devices in private).

That said, I think we should think about how we can enable more user
control of such features. If I open media tabs in the background, I
probably don't want them to autoplay at all. And then, there are
situations on all my devices where I may want autoplay and situations
where I may not. How could we give the user control over autoplay in an
intuitive and easy way? Is there a good way to do that on mobile form
factors as well?

KaiRo

[Tetsuharu OHZEKI]

2013/12/8 Robert Kaiser <ka...@kairo.at>:

> I personally have not yet seen any arguments that would really apply for
> making things different between mobile and desktop in your discussion, and I
> think we should not make functionality different between form factors or
> products when there is no good reason to make them different.
> IMHO, what's named "Firefox" should work the same everywhere unless there is
> a really good reason why a different variant should behave differently (and
> there surely are often good reasons, but I haven't noticed those in this
> discussion yet - nobody says I won't often use my laptop in public or my
> mobile devices in private).

Ideally, I agree that what's named "Firefox" should work the same everywhere.
Though, There are some difference between "desktop" and "mobile" for
general usecases. Mobile including tablet would be more used in public
space than desktop. I don't say laptops are never used in public
space.
Of course, some people use their laptop in very crowded train like
which runs in Tokyo. Other some people use their mobile devices in
only private. But they are limitless.

I think that we need to discuss it based on general usecases at first.
On that basis, we should discuss how we bypass or resolve some
problems.


2013/12/8 Robert Kaiser <ka...@kairo.at>:

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



--
Tetsuharu OHZEKI
saneyuk...@gmail.com

[Robert O'Callahan]

Maybe we can build something clever based on the per-window volume and
muting infrastructure in bug 923247? I think easy per-tab muting is a good
thing to try here.

[Robin Berjon]

On 08/12/2013 15:03 , Robert Kaiser wrote:
> That said, I think we should think about how we can enable more user
> control of such features. If I open media tabs in the background, I
> probably don't want them to autoplay at all.

I think that's the key part. Is there any common usage scenario in which
autoplay on an inactive tab is not a nuisance? Who hasn't reopened
Firefox with a bunch of tabs loading and then had to scramble through
them to find which ones were making noise?

I reckon that making autoplay depend on page visibility would be enough
to remove the need for user control here, so as to keep things simple.
IMHO the only question is whether that would break content and possibly
require a spec change. I suspect not for content; on the spec side it
already says that UAs don't have to support it.

--
Robin Berjon - http://berjon.com/ - @robinberjon

[Gervase Markham]

On 08/12/13 12:28, Tetsuharu OHZEKI wrote:
> On today's web, there are many "interactive" web sites which play
> sounds when open them.

I suspect this is somewhat dependent on your culture and environment;
it's not a problem on the set of websites I visit :-)

> Some of them are not controlled by users
> because they doesn't not provide any control.

If a website played music at me with no way to turn it off, I'd probably
leave and never come back...

Personally, also, "it makes it easier for people to hide their porn use
from others" is not an argument which gets much traction with me.

Gerv

[Panos Astithas]

I don't know about that use case, but mine involves Spotify and Soundcloud,
which I have pinned as app tabs. Every now and then I will close the
browser before shutting down the laptop, without remembering to pause the
music in one of those tabs. Booting the laptop afterwards in a public place
never fails to annoy some people.

Panos

[Benjamin Smedberg]

On 12/8/2013 4:31 AM, Tetsuharu OHZEKI wrote:
>
> I welcome your feedback to polish Firefox for mobile and web.

Note that autoplay is not the most interesting case, because most of the
top video sites don't actually use it; instead they use a scripted
.play() call on load.

https://bugzilla.mozilla.org/show_bug.cgi?id=944876 may be relevant: in
that bug I'm willing to mentor somebody to add a hidden pref for
additional control over autoplay behavior.

For desktop Firefox, I don't think we'd ever want to disable autoplay
*by default* in the foreground tab: many people expect their youtube
video to just start if they click the link. I suspect that, as discussed
earlier on this thread, it might make a lot of sense to delay starting
media in a *background* tab (e.g. opened via middle-click). Then we'd
autoplay when the video comes into the foreground. We could even
implement a setting where all media pause in a background tab.

Before we decide on new defaults, I think we should do some experiments
with what we can actually accomplish in bug 944876, hopefully get some
prototype extensions out for people to experiment with, and then come
back and consider what preferences and defaults it actually makes sense
to expose.

--BDS

[Henri Sivonen]

On Sun, Dec 8, 2013 at 11:49 AM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> I think it's important to have an easy way to mute/unmute the browser, but
> disabling autoplay is probably not the right way to address these issues.

A pref to disable autoplay might be, though.

If autoplay is disabled by default, Web authors will take
counter-measures and start playback from JavaScript. However, if
autoplay is honored by default but the user can turn in off as a pref,
it could be that Web authors won't bother to take counter-measures.

Other than that, it might be worthwhile to investigate if there's a
bug that causes various non-YouTube (Brightcove?) video embeds to
autoplay on Android. On multiple occasions, when I've navigated to
TV-affiliated news sites that have had textual news and a clip from
the same organization's TV news, the clip has started to autoplay on
Android. (Sadly, I haven't collected URLs, though I know I should
have.)

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Mike Hoye]

On 12/8/2013, 4:49 AM, Robert O'Callahan wrote:
> Don't these arguments apply to desktop Firefox used at work, in an Internet
> cafe, or in a library, as well?

Media is a power hog on mobile, so it's worthwhile to handle it
differently there.


- mhoye

[Chris Pearce]

On 12/10/2013 4:38 AM, Henri Sivonen wrote:
> On Sun, Dec 8, 2013 at 11:49 AM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>> I think it's important to have an easy way to mute/unmute the browser, but
>> disabling autoplay is probably not the right way to address these issues.
> A pref to disable autoplay might be, though.

We have this, set media.autoplay.enabled to false.

[Reuben Morais]

Note that B2G doesn't have an about:config.

-- reuben

[Tetsuharu OHZEKI]

2013/12/10 Reuben Morais <reuben...@gmail.com>:

> Note that B2G doesn't have an about:config.

We can resolve with to add an option to gaia UI.

--
Tetsuharu OHZEKI
saneyuk...@gmail.com

[Tetsuharu OHZEKI]

2013/12/10 Benjamin Smedberg <benj...@smedbergs.us>:

> https://bugzilla.mozilla.org/show_bug.cgi?id=944876 may be relevant: in that
> bug I'm willing to mentor somebody to add a hidden pref for additional
> control over autoplay behavior.

Sounds good. I feel this approach is more smart like roc said.

> For desktop Firefox, I don't think we'd ever want to disable autoplay *by
> default* in the foreground tab: many people expect their youtube video to
> just start if they click the link. I suspect that, as discussed earlier on
> this thread, it might make a lot of sense to delay starting media in a
> *background* tab (e.g. opened via middle-click). Then we'd autoplay when the
> video comes into the foreground. We could even implement a setting where all
> media pause in a background tab.

I almost agree. For desktop Firefox, we should not (cannot) change the
default behavior for autoplay. This is (historical) protocol. Even if
we provide other click-to-plays options, we might not change the
default.

However, for desktop, I don't think it's good that providing as
default to delay starting in background tabs. This is same with that

many people expect their youtube video to just start if they click the

link. Some of them also expect their youtube video start in background
tabs as podcast.

For mobile, this delaying approach is well for saving power. I feel
this approach make sense.

--
Tetsuharu OHZEKI
saneyuk...@gmail.com

[Hubert Figuière]

On 09/12/13 08:44 PM, Tetsuharu OHZEKI wrote:
> For mobile, this delaying approach is well for saving power. I feel
> this approach make sense.

Power? How about not blowing through your data cap allowance or paying
and other hefty charges....

Very few countries have cheap unlimited data over cellular.

Hub

[Hubert Figuière]

On 08/12/13 04:49 AM, Robert O'Callahan wrote:
> Don't these arguments apply to desktop Firefox used at work, in an Internet
> cafe, or in a library, as well?
>

> I think it's important to have an easy way to mute/unmute the browser, but
> disabling autoplay is probably not the right way to address these issues.

It should be noted that here on desktop I do have
`media.autoplay.enabled=false` (I hate videos that autoplay) and this
still doesn't stop YouTube. [1]

So while I'm all for disabling video and sound autoplay across the
board, that config flag isn't enough to get rid of that nuisance. [2]

I'm not sure if it is a bug or a feature, but if you tell me it is a
bug, then I'll gladly file one.

Hub

[1] before I get told CTP, I don't have Flash, so this is only for the
case the video is playable without Flash.
[2] I have already noted the disagreement of opinion here.

[Tetsuharu OHZEKI]

2013/12/11 Hubert Figuière <h...@mozilla.com>:

> Power? How about not blowing through your data cap allowance or paying
> and other hefty charges....
>
> Very few countries have cheap unlimited data over cellular.

Of course, it includes network data traffic. I hope it saves power/data cost :)

--
Tetsuharu OHZEKI
saneyuk...@gmail.com

[Tetsuharu OHZEKI]

2013/12/11 Hubert Figuière <h...@mozilla.com>:

> It should be noted that here on desktop I do have
> `media.autoplay.enabled=false` (I hate videos that autoplay) and this
> still doesn't stop YouTube. [1]

I seem that Gecko's implementation of HTMLMediaElement.play() doesn't
handle `media.autoplay.enabled`.
http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLMediaElement.cpp#2112

--
Tetsuharu OHZEKI
saneyuk...@gmail.com

[Chris Pearce]

On 12/11/2013 3:07 PM, Tetsuharu OHZEKI wrote:
> 2013/12/11 Hubert Figui�re <h...@mozilla.com>:

>> It should be noted that here on desktop I do have
>> `media.autoplay.enabled=false` (I hate videos that autoplay) and this
>> still doesn't stop YouTube. [1]
> I seem that Gecko's implementation of HTMLMediaElement.play() doesn't
> handle `media.autoplay.enabled`.
> http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLMediaElement.cpp#2112
>

Because play() and autoplay are different.

We could add a pref that caused HTMLMediaElement.play() to only work if
called from inside a user generated event handler (i.e. mouse click, key
press). That would achieve most of what you want, and is very easy to
implement.


Chris P.

[Alex Jordan]

On Dec 10, 2013 6:30 PM, "Chris Pearce" <cpe...@mozilla.com> wrote:
> We could add a pref that caused HTMLMediaElement.play() to only work if
called from inside a user generated event handler (i.e. mouse click, key
press). That would achieve most of what you want, and is very easy to
implement.

This seems like it might break e.g. games.

[Chris Pearce]

This would be preffed *off* by default of course. We could make this
only for <video> elements in documents. But that's still defeatable. You
really want something like what roc suggested. This is just easier.


Chris P.

[Robert Kaiser]

Henri Sivonen schrieb:

> If autoplay is disabled by default, Web authors will take
> counter-measures and start playback from JavaScript. However, if
> autoplay is honored by default but the user can turn in off as a pref,
> it could be that Web authors won't bother to take counter-measures.

It probably should be a visual pref somewhere, but I agree that the
default should be to enable autoplay on foreground tabs.

On background tabs, I think all media should be click-to-play by default
though, if possible - both for not needlessly waste power (which might
be just as precious on a laptop than a mobile device, the lines are
blurry anyhow) and for not surprising people (or making multiple tbas
that one opens in the background all run autostarted media elements at
the same time, creating a big jumble on the speakers).

KaiRo

[take...@gmail.com]

Hi,

I think two prefs are needed.
In addition to the pref discussed in this topic, "make all media on any tabs be click-to-play" is needed to ensure the Web Accessibility.

UAAG2 (User Agent Accessibility Guidelines 2.0) LCWD [1] contains two "Level A" success criteria related to this topic.

- 2.11.1 Time-Based Media Load-Only
The user can override the play on load of recognized time-based media content
such that the content is not played until explicit user request.
- http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/#sc_2111

- 2.11.2 Execution Placeholder
The user can request a placeholder instead of executable content that would
normally be contained within an on-screen area (e.g. Applet, Flash),
until explicit user request to execute.
- http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/#sc_2112

# Please refer "Implementing UAAG 2.0" for user scenarios of each success criterion.

IMHO, to comply UAAG2 (LCWD), we need only one pref: "make all media be click-to-play". However I think lexer prefs are preferred for general cases and I agree that we implement such prefs.

To summarize my opinion, "make all media be click-to-play" should be implemented when we implement the prefs (or features) that control autoplay/play().

Best wishes,

Takeshi

[1]
User Agent Accessibility Guidelines (UAAG) 2.0
http://www.w3.org/TR/2013/WD-UAAG20-20131107/

Implementing UAAG 2.0
http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/


Robert Kaiser: