On Wednesday, August 8, 2018 at 4:58:28 PM UTC-7, Jan-Ivar Bruaroey wrote:
> 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.
Thank you for persisting on this issue. I have thought on it and I agree there
is a valid concern here about sites using allowedToPlay being steered away from
the path where they'd hit the doorhanger.
Our current thinking here is to have allowedToPlay returned one of {"allowed",
"prompt-required", "blocked"} instead. Then sites which assumed they can play
if video.allowedToPlay!="blocked" would try to play and hit our prompt.
Does that alleviate your concerns?
> > 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?
We've not been able to come up with a reasonable solution for creating a
default whitelist, so we opted to avoid the problem altogether by giving users
control over what they want to whitelist.
> >> 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 don't understand why you consider the prompt complicated. Can you try saying
why in another way?
>
> >> 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.
That is not a rhetorical question. I considered an approach like this and
discarded it.
Pinned tabs and push notification permissions are noisy signals.
People pin tabs for all kinds of reasons. People pin tabs to "super bookmark"
things that they don't want to autoplay. We had a raft of bugs filed where
people pin youtube tabs of channels they like to watch a lot, but they don't
want those to autoplay.
Push notifications aren't a good signal either. Lots of sites that we don't
think should be autoplaying request push notification permission, like news
sites. YouTube also requests push notifcations under some conditions I don't
understand, and as stated above not everyone wants YouTube to autoplay.
Push notifications and autoplay media are not the same thing, and it is likely
to lead to confusion if we group their permissions together.
cpearce.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
