On Saturday, July 7, 2018 at 5:04:28 AM UTC+12, Mounir Lamouri wrote: > 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? >
That's correct. If any document in the hierarchy is gesture activated, the entire hierarchy is activated. > > > > > > 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? Setting volume to 0 is another easy way to make videos inaudible, and we want inaudible video to be able to autoplay. So I'd flip that question around and ask why you think volume=0 video should not autoplay but a video without an audio track should? Both are inaudible. > > > > > 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? Do you have data on what proportion of media elements which autoplay don't have an audio track? It seems to me to be much easier for web developers to be certain that a media resource is inaudible by using the muted attribute than by relying upon what tracks are contained in the resource. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
