Nicolas Barbulesco Reporter
	Description • 11 years ago

Firefox 25.0.1, Mac OS X Mavericks.

It would be nice to have click-to-play — per element, of course — for HTML5 videos. Now it is time for it.

It would avoid the cacophony I have just encountered. I had this video www.youtube.com/watch?v=CDZlgpgcHjw , and I Apple-clicked on a link, to open it in background. The two videos played at the same time.

Thank you.

	Benjamin Smedberg
	Comment 1 • 11 years ago

There are a couple different possibilities here:

1) disable autoplay, but allow site .play() scripting to continue working
2) disable autoplay and ignore .play() if it's not from a click-type event (using the same logic we use for popup windows)
2) disable autoplay *and* scripted .play() in all cases

Can we try #1 first and see whether popular video sites work the way you want? That's the simplest solution and why the autoplay was introduced in HTML5 in the first place.

This has nothing to do with ctp plugins, FWIW.

	Nicolas Barbulesco Reporter
	Comment 2 • 11 years ago

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)

> There are a couple different possibilities here:
> 
> 1) disable autoplay, but allow site .play() scripting to continue working
> 2) disable autoplay and ignore .play() if it's not from a click-type event
> (using the same logic we use for popup windows)
> [3)] disable autoplay *and* scripted .play() in all cases
> 
> Can we try #1 first and see whether popular video sites work the way you
> want? That's the simplest solution and why the autoplay was introduced in
> HTML5 in the first place.

[I corrected : 3).]

I understand that there is an attribute "autoplay" and a method play(). It makes sense that a site wanting autoplay use the attribute autoplay. However, heavily-scripted sites like Youtube and Dailymotion will probably use the method play(). As well as sites deliberately wanting to override user control (ads...). So strong user control will probably be needed.

So I suggest this :

 A) Implement choice 1) and make it the default behaviour.
 B) Implement choice 2) and make it available as an option.

A) is most wanted, B) may come later.

Thank you Ben, these improvements will be a great step !

Nicolas

	Benjamin Smedberg
	Comment 3 • 11 years ago

I am not going to implement this feature, but I will try to mentor somebody who wants to write a patch for this behind a hidden about:config pref. I think #3 will certainly break youtube/dailymotion since they implement their own video controls and the only way to play a video is to use their controls.

The Firefox default will likely be to honor autoplay, although there are later spinoffs we can consider like disabling any kind of video playback in background tabs until they come to the foreground, and then honoring autoplay. So let's not get caught up in what the default setting is, and focus on the basics requested here.

jst, can you confirm before we get too far into this that you'd accept a patch to implement this kind of control via pref?

	Johnny Stenback (:jst)
	Comment 4 • 11 years ago

I'm certainly open to experimenting with this behind a pref, yes. Once that's in place, we can start making a case for whether we have the right approach and whether it's worth pushing this further than behind a hidden pref etc.

	Tetsuharu OHZEKI [:tetsuharu] (UTC+9)
	Comment 5 • 11 years ago

Related: https://groups.google.com/d/topic/mozilla.dev.platform/Mpuy7JVxlQk/discussion

	Tetsuharu OHZEKI [:tetsuharu] (UTC+9)
	Comment 6 • 11 years ago

If we implement this feature, we should delay "play" event's dispatch/propagation.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 7 • 11 years ago

To handle the situation of comment #0, I think a good policy would be to mute any tabs that are loading in the background (i.e. that haven't ever been the foreground tab yet). Bug 923247 has infrastructure that would allow this to be implemented in the Firefox front end.

	Nicolas Barbulesco Reporter
	Comment 8 • 11 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)

> To handle the situation of comment #0, I think a good policy would be to
> mute any tabs that are loading in the background (i.e. that haven't ever
> been the foreground tab yet). Bug 923247 has infrastructure that would allow
> this to be implemented in the Firefox front end.

Mute ? You mean that the videos would play — and suck the processor — but without the user knowing it ? That would be even worse !

	Abhilash Panigrahi
	Comment 9 • 10 years ago

I'd like to work on this bug. You mentioned in bug 948215, that tab muting would fix the problem, As

	Abhilash Panigrahi
	Comment 10 • 10 years ago

(In reply to Abhilash Panigrahi from comment #9)
> I'd like to work on this bug. You mentioned in bug 948215, that tab muting
> would fix the problem, 

As nicolas mentioned, wouldn't that be unnecessarily using your computer's resources?

	Benjamin Smedberg
	Comment 11 • 10 years ago

There is already the hidden pref media.autoplay.enabled, so part 1 is probably already done (you should check this!)

In terms of part 2, you're looking at restricting the behavior of HTMLMediaElement::Play: http://mxr.mozilla.org/mozilla-central/source/dom/html/HTMLMediaElement.cpp?force=1#2139

Based on the DOM state similar to how we control window.open. So it might be good enough to start out using nsGlobalWindow::GetPoupControlState() similar to how window.open itself checks: see http://hg.mozilla.org/mozilla-central/annotate/cb8ad2251c09/dom/base/nsGlobalWindow.cpp#l11797

And if we're in a popup-blocking state, reject the load by setting aRv to an error result.

	Benjamin Smedberg
	Comment 12 • 10 years ago

Note that muting could be sufficient for *audio* loads because we can simply avoid decoding the audio while the tab is muted. This is not sufficient for video loads unless the tab is both muted and invisible, which is why solving the video case is more interesting.

	Luke
	Comment 13 • 9 years ago

I'm using the latest Firefox and I have "media.autoplay.enabled" set to "false". I also have uBlock installed. Even then I am experiencing a major drain on my DSL speed when visiting e.g. YouTube. The videos will download in the background even though they aren't playing. The same goes for new HTML5 ads.

I hope that someone comes up with a complete click-to-play solution that does the following.

1) Complete disallows any attempt to load content inside of <embed>/<video> tags to save bandwith.
2) Only enables said content when I "click" to play that said item. Similar to how the click to play flash plugin used to work would be nice.

	chinhanglun
	Comment 14 • 8 years ago

Hi, I'm new to open source. I've already build Firefox and I'm interested in contributing to this. Would anyone mentor me, give me some advice on how to start as well as setting a more concrete goal.

	timbugzilla
	Comment 15 • 7 years ago

Any chance that this could be implemented? Autoplaying html5 video is becoming a major annoyance, and this feature would be a big improvement in user experience.