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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
