Topics of interest:

  • Ads
  • Differences across browsers
  • Not muted playback
  • Firefox: Still gathering feedback, working on what the 'right thing to do' is
  • What can and cannot be done, e.g. buffering, multiple tags, how does it relate to tab muting
  • How does MEI work (Chrome), how are white lists managed (Safari) - are white lists better than user settings?
  • Should we mute and show captions? Or click-to-play?
  • Can a single page switch between HLS and DASH and continue playing (switch libraries)?
  • What is the right way to call "Play"? Promises are broken (?)
  • How can players/ media companies figure out capabilities of browser and timelines, what guidance should they give their clients who depend on SEO traffic & ad revenue
  • How can players work with ad vendors to make sure they are up to date
  • Are there other heuristics that could be used to govern autoplay (e.g. a lot of text on the screen vs. no text?)
  • Promises: A list of reasons why a Play promise might be rejected (e.g. user gesture required); promise error stack traces so they can see where they came from; what is result of a promise being rejected, is video paused? What are the bad states a video tag can get into?
  • What is the right sequence for loading a video tag and then choosing play?
  • How can they find out whether they've had a user gesture (e.g. is a window event a user gesture?)
  • Can they detect whether Play will work without having to try it (an API to detect autoplay)
  • Predictability

Current policies


  • a web page cannot generate audio without user consent. Audio must be played within 1s of last user gesture, or started in response to user gesture.
  • Once you start playing, a video can continue doing its thing as long as a page existed.


What happens if you programmatically unmute (iOS: pauses video, you need a user gesture to play. Chrome: Won't turn on audio, not sure behavior)

MEI sync'd for the user between browsing sessions? A: Yes, see MEI design doc:

Safari 11 Desktop policy (JER PLEASE REVIEW)

  • IFrames? are muted autoplay only (considering attribute to pass autoplay policy, just learned Chrome allows this. Once we ship may add this attribute.)
  • If you click inside an IFrame? and it starts video playback, that lets it play as much video as it wants (with audio). Other IFrames? don't get that permission.
  • Same policy applies to the top level page.
  • White list is different than MEI. Algorithm was used to determine sites to allow playback with sound. This is based on top-level origin (e.g. YT embed doesn't get autoplay)
  • Apple recommends everyone do muted play first (unless you know that you're on the white list). Users love the ability to block things making sound.
  • Users have a setting to block all autoplay, or allow all autoplay, including IFrames? on a site by site basis. The reason they have this is because there are a ton of websites which are totally broken - e.g. a site that posts a video w/ a spinner and nowhere to hit 'play'; clicking causes video to pause.
  • If you click on any video player in a context (a page or an IFrame?), all videos in that context are allowed to play with sound.
  • When user navigates to another page, autoplay policy resets (different than Chrome)
  • In Safari the pause attribute WILL reflect the pause state and this happens before promise returns; can be used without checking promise ('probably'). But DO NOT DEPEND ON THIS.
  • Safari does NOT have a way of querying autoplay without trying a Play
  • NOTE: WebKit? blog post needs to be updated with some of these changes, specifically the fact that when you play one video element, all other video elements on that page will be allowed (Safari only)

Chrome 63 with flag, not getting a pause event, rather getting the promise rejected. (Rob Walch)

Firefox policy

They basically do the same as Chrome on mobile.

  • Currently the mobile and desktop both reject promise if playback is not allowed.
  • Mobile has a UI allowing user to ???
  • Gathering feedback


  • Apple rejects promise similar to Chrome if a play is requested but policy won't allow it.
  • Apple will also pause muted autoplay video when offscreen. Audible, or manually played video, will not pause when offscreen. This will fire a pause event.
  • (Note: If MSE playback they'll seek to the most recent seekable range if live and user continues)

Firefox and background video:

  • Stop decoding when invisible and then hustle to catch up

Question for Apple: How about iOS, will this be loosened up and aligned with desktop?

  • They will look into this.

Apple: If you click on one video and it plays with sound and other videos are playing you have to programmatically unmute the others

Apple: Can bucket playbacks in native apps into a few buckets

  • Netflix - hit play, it plays
  • Facebook - you scroll past a lot of non-playing videos
  • Lots of cases w/ animated images or video w/out audio

Does preload affect Play? Autoplay is in theory supposed to limit data being used?