On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote: > On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote: > > Hi Mounir, > > > > Replies inline below... > > > > > > On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri <mou...@lamouri.fr> wrote: > > > > > Hi Chris, > > > > > > Very excited to see Firefox going forward with autoplay blocking. A couple > > > of comments inline. > > > > > > On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote: > > > > DETAILS: > > > > > > > > We intend to block autoplay of HTMLMediaElement in tabs which haven't > > > > had user interaction. Web authors should assume that they require a user > > > > gesture (mouse click on a "play" button for example) in order to play > > > > audible media. > > > > > > I assume you will not allow autoplay when navigating into the same > > > website? What about iframes? Will they be allowed to autoplay if the main > > > frame is allowed to? Will the feature policy be used instead? > > > > > > > > A gesture in any document in the document hierarchy gesture activates the > > top level document, and a document uses the top level document's gesture > > activation status to determine whether it can play (our implementation > > actually differs a bit, but this is the effective behaviour). Gesture > > activation status isn't preserved across navigation. So if the top level > > document navigates, the incoming document hierarchy won't be able to > > autoplay. If a non-top-level document navigates, the new document in the > > iframe will still use the top-level document's gesture activation status, > > and so the iframe's new content document will be able to autoplay. > > With autoplay coming from third party content, do you consider using Feature > Policy to block cross origin iframes by default?
I won't rule out doing something in the spirit providing a way for sites to control whether subframes are allowed to autoplay in future, but we won't be doing it as part of our MVP. > > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still > > > > allowed to play. > > > > > > Chrome and Safari allows autoplay only when the playback is muted. The > > > spec allows side effect for setting `muted = false;`. What will happen for > > > a website that changes the volume from 0 to something else? > > > > > > > > > > If an HTMLMediaElement starts playing with muted/volume=0 and then script > > sets it to unmuted/volume>0, then we'll pause the media. > > The volume=0 behaviour isn't compatible with Blink and WebKit. Would it be > worth only use muted for consistency between browsers? This code gives me the impression that WebKit does in fact block volume > 0 media: https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303 So maybe Blink should consider changing to be consistent with other browsers? ;) > > > Also, will autoplay be allowed when the video has no audio track? > > > > > > > > > > > Our autoplay logic ignores whether the media resource has an audio track; > > it makes our implementation simpler, and if an author knows a media should > > be inaudible, they can set the muted attribute. So a video element playing > > a media resource with no audio track and without the muted attribute would > > still be blocked. > > FWIW, WebKit uses the audio track availability and Blink intends to do this > at some point. I actually implemented this, landed it, and then ended up reverting it. The main problem here is if HTMLMediaElement.play() is called before the load algorithm has reached readyState>=HAVE_METADATA, you won't know whether the media you're loading has audio tracks. If you hit this case, you have two options; decide whether to block immediately based on incomplete information, or return the promise and wait until you reach loadedmetadata before deciding whether to play. If you decide based on incomplete information you become racy; the decision you make on incomplete information may contradict the decision you'd make based on more complete information when the load is further along, and network loads are inherently racy. That seems bad. If you return the promise and yield control to JS you run into compat issues. As Jean-Yves mentioned, some sites expect that HTMLMediaElement.play() synchronously sets the paused attribute to false and enqueues tasks to fire "play", "playing" etc. Safari appears to have a quirks mode where they pretend to play and then dispatch "playing" and "pause" if they reach readyState HAVE_METADATA and they discover an autoplaying media has an audio track (even if they didn't play, they'll dispatch playing). Experimenting with such hacks in Gecko led to compat issues. Even without such hacks I still ran into many subtle problems caused by timing changes due to the play/playing events being dispatched later on in the load, and by the paused attribute changing at a later time than script expects. That was enough to convince me to give up and just rely on the muted and volume attributes to express inaudibility. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
