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. 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. 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. > > > 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. > 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? > 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. 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. cpearce. > Thoughts? > > .: Jan-Ivar :. > > >> cpearce. > > > > .: Jan-Ivar :. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
