On Tuesday, July 10, 2018 at 7:30:38 AM UTC+12, Mounir Lamouri wrote: > On Fri, 6 Jul 2018, at 15:35, Chris Pearce wrote: > > 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: > > > > > > > > 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. > > `muted` and the presence of an audio track clear distinguishable signals as > they are boolean and declarative. A video that has volume 0 could be for > various reasons. Furthermore, requiring `muted` or `volume` seems slightly > odd as they both apply to the HTML content while the audio track metadata is > at a different level so can offer benefits if for example, modifying the > content is possible but not the page. > > FWIW, we could add this in Blink if it can help with x-browser compat but > I've never heard of a website asking for this nor did I see articles > suggesting using volume=0 even from Apple. Given that it would require the > website to set `video.volume = 0;` in script, it is less powerful than > `muted` that can be used as a content attribute too. > > > > > > > > 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. > > I agree that setting `muted` should be enough and that's why Blink does this > but we had developers complain to us that muted autoplay didn't work and when > digging into it, they didn't set muted and "it worked on Safari". I would > rather have compatibility across browsers if we can even if that mean > implementing things that I wouldn't otherwise. If Gecko has a strong > position, we should consider asking Safari to drop this behaviour instead of > having web developers pay the cost. > > Chrome should have metrics about audio track and muted autoplay. I will look > into them. > > In general, what I'm worried about is that Firefox's implementation doesn't > match Safari's nor Chrome's but something in between which isn't going to > help developers. I understand that general autoplay policies are still young > and we may want to wait a bit before talking about merging policies but muted > autoplay is straightforward enough that we should aim for compatibility. For > what it's worth, Chrome's implementation is made so that if it works on > Chrome, it will work on Safari (with `playsinline` added on iOS). > > -- Mounir
Compatibility with other implementations is an important consideration for us too. We don't want pages that work in either Safari or Chrome to not work in Firefox. So if you can convince Safari to change to not allow volume=0 to autoplay, I commit that we will remove that provision too. I'd prefer for authors to rely on the muted attribute rather than relying on whether a media doesn't contain an audio track, as it's quite opaque whether a media has an audio track. Just setting the muted attribute is simpler and more reliable. That said, I'm not strongly opposed to allowing media without an audio track to autoplay, as clearly they're not audible. I would however like to get together and agree with other browser vendors how we'd resolve the race issue I mentioned above before shipping that provision. Chris Pearce. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
