On 8/8/18 12:43 PM, Chris Pearce wrote:
Hi Jib,
I appreciate that you care passionately about our users' best interests.
Seeing as you asked "why don't you just?"... Here's why we "didn't just"...
On Tuesday, August 7, 2018 at 7:51:50 PM UTC-7, Jan-Ivar Bruaroey wrote:
On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote:
On 8/1/18 3:36 AM, Chris Pearce wrote:
I think the only thing that you're missing is how vehemently some
sites are in their desire to avoid the doorhanger prompt.
No, I'm also missing why we should listen to them.
If Netflix fights our doorhanger, then they're fighting our best attempt
to whitelist them.
To clarify, I care about Netflix, which is why I question giving up on
persisting autoplay for them, which is what allowedToPlay does.
AFAICT allowedToPlay's sole purpose is to avoid our doorhanger.
Sites are already trying to feature detect whether they can autoplay audible
video and present different behaviour when they can't. There are established
solutions for this that pre-date us talking about doing a doorhanger. So I
don't think we can conclude that authors are doing this to avoid our doorhanger.
Many of the major US news sites as well as the BBC now try to autoplay audibly,
and if that is blocked, they fallback to playing inaudiblby and showing an
unmute button.
Right, because of Chrome. This is my point. allowedToPlay plays into
Chrome's autoplay policy (pardon the pun), not ours.
Chrome's "path to whitelisting" policy appears to be: Don't bother
trying unless you're whitelisted or until user engagement kicks in.
Our "path to whitelisting" policy appears to be: Try, and we'll ask the
user to whitelist you. If you don't try, we can't help you.
From a web developer's perspective, this seems incompatible.
So allowedToPlay makes sense in Chrome, not in Firefox at the moment.
Seems to me we need a better "path to whitelisting" strategy, before we
help bury the one we have.
Once we have a working "path to whitelisting" policy, that's not
thwarted by allowedToPlay or modernizr, I see no problem with
allowedToPlay, but it appears we don't.
What concerns me, is we seem intent to land without this in place...
Firefox 62: Netflix autoplays
Firefox 63: Netflix no longer autoplays
Chrome: Netflix autoplays
:-(
I was also pointed at https://www.npmjs.com/package/modernizr which which is a
web framework which is feature sniffing whether audible autoplay works by
trying to play a media with a silent audio track. It does this on load, even if
the page author hasn't signaled any intention to use video. NPMJS lists that as
getting 41k weekly downloads, and this framework would cause sites that are not
obviously using media to have a prompt appear in Firefox for maybe no benefit.
I want to avoid that.
Many of these packages which detect whether audible autoplay works have
timeouts so that if the play() promise is not resolved within some short time
they assume that they can't autoplay, which doesn't play nice with us delaying
resolving the play() promise while we wait for the user to click the prompt.
Sites were trying to detect whether they can audibly autoplay before Firefox
had a prompt, so making it easier/cheaper/faster for them whilst also having a
side benefit of avoiding the prompt seems reasonable.
I've heard two reasons to fear our doorhanger:
1. Sites doesn't want to get blocked.
This seems bogus, because "getting blocked" appears no different from
avoiding the prompt with allowedToPlay. Both prevent the prompt.
Try it yourself: https://jsfiddle.net/jib1/rwkLaofx/show
Press "Don't Allow", then click anywhere on the page to play.
In other words, users aren't blocking audio, only un-gestured audio,
which shouldn't matter to sites who already avoid it with allowedToPlay.
It's not clear to me that "Sites doesn't want to get blocked" is in our users'
interest, so I'm not going to contest this.
Also, allowedToPlay will never suddenly return true if used to suppress
the prompt, because we have no other whitelisting strategy.
allowedToPlay will start returning true when the page is gesture activated.
Sorry I misspoke. I meant allowedToPlay will never suddenly return true
*on pageload* if used to suppress the prompt, because we have no other
whitelisting strategy.
For example, when I open into Netflix, I am greeted with a profile selection
screen from which I can choose between my profile, my wife's profile, or my
kids' profile. The click to select a profile gesture activates the tab for me,
so I normally don't see the prompt on Netflix FWIW.
2. User testing shows many users don't understand the prompt.
This one makes sense to me. If avoiding our one-time prompt matters more
to them than autoplay itself, it's a sign our prompt isn't great. We
should fix that, not help sites opt out.
The prompt exists because there are some cases where users have a reasonable
expectation that autoplay audible audio should work without interacting with
the page first. For example deep links into YouTube/Netflix videos,
notification sounds for messaging sites, and the long tail of things that
Chrome broke in https://bugs.chromium.org/p/chromium/issues/detail?id=840866
(some of which are WebAudio, which we're not blocking yet).
I wanted to solve this by shipping our own custom whitelist (like Chrome and
Safari), but we couldn't figure out how to objectively generate one without
phoning home with our users' browsing history, and that's against our data
collection policies.
So how are we going to solve this?
Here's my take on our prompt:
I love that we went with a visible user agent feature instead of
breaking the web. Even the permission part, partly. The management part.
But the prompt itself is too complicated. It's hard to glean how little
is at stake: delaying audio by a mere click in many cases.
Try the fiddle again, ignore the prompt and just click somewhere on the
page. Tone.
We are considering switching from the document gesture activation strategy to only
allowing play() calls inside a JS context that originated inside a user generated event
handler (like how Safari blocks autoplay). But currently that is blocked on a bunch of
work to make EventStateManager::IsHandlingUserInput() return true for JS contexts running
in a setTimeout or promise continuation that originated in a user generated event
handler. That would eleviate some of your "WTF?" response here I think.
No, it doesn't change that the prompt is too complicated IMHO.
I think we need to rephrase this as a helpful user agent:
_/\_________________
| |
| Wanna hear sound ? |
| |
| No | Yes |
`--------------------'
or
_/\_______________
| |
| Sound blocked. |
| |
| Don't | Thanks |
`------------------'
Then have the user agent set the permission wisely.
To be clear, you're only unhappy with the wording of the prompt? Everyone has a
diffent opinion on what the best wording is FWIW...
By putting the agent in charge, we might even get away with a path to
whitelisting without a prompt, where the user agent implicitly turns the
permission on for well-behaved sites after users have interacted
sufficiently with gesture-driven audio, without signs of distress.
I had already considered approaches like this. How would you unblock sound on
sites like slack/irccloud, or the long tail of sites on the Chroium bug above,
that don't have play buttons for their audio playback?
That's a great (hopefully not rhetorical) question, that I think is
squarely in user agent territory. We should try to solve that and even
refine it over time IMHO.
I keep slack open as a pinned tab, and I have given it notification
permission. I also interact with it a lot. Lots of signals there.
This seems similar to Google's engagement system, except it's visible,
so users can override the agent should it get it wrong, since it's still
permission-based at heart.
Then allowedToPlay might make sense.
It's not clear how this is effectively different from Chrome's MEI, which was
poorly received.
It's different because users can see what mode they're in, thanks to how
we visualize permissions in the UI.
FWIW, I see a lot of feedback on my twitter stream of people who love that
Firefox puts them in control of whether sites autoplay. Whether the same
sentiment will also be present in our release population remains to be seen.
I like it too. That doesn't mean the prompt isn't too complicated for
most folks. I don't know about you, but the people I follow on Twitter
tend to be quite technical. ;)
.: Jan-Ivar :.
cpearce.
Thoughts?
.: Jan-Ivar :.
cpearce.
.: Jan-Ivar :.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
