On Fri, 6 Jul 2018, at 00:49, Chris Pearce wrote: > 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.
To clarify, your MVP will allow subframes to autoplay if the main frame can, right? > > > > > 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? > ;) That's interesting. We spec'd something in HTML and Safari did not mention this. It's not in their documentation nor ours. What's the benefit of allowing volume=0 to autoplay? > > > > 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. Thanks for the feedback. The reason why we did not implement this yet is for similar reasons: getting the information may be async and our code make this decision fairly early today. This said, I think this would be beneficial for web developers. Is this something you think Gecko may implement at some point? -- Mounir _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
