This was reported to me by someone on nightly (45) and I reproduced it on Dev (44) and release (42). Set media.autoplay.enabled to false and straight HTML5 videos don't play when you click the large play button (overlay) at the center of the video. http://video.webmfiles.org/big-buck-bunny_trailer.webm This also applies to other videos such as vimeo and youtube: https://vimeo.com/channels/staffpicks/147327791 https://www.youtube.com/watch?v=3Osphb4LqBY Hitting the play button at the bottom left of the video usually makes it play. Sometimes this requires a couple of clicks like on youtube ("pauses" then plays). Discovery that the lower-left play button plays it is not a guarantee for users and this makes for an overall poor experience.

Happening on FF43 too. When media.autoplay.enabled is false, the youtube player freezes at the beginning. You can make it play if you click somewhere on the seek bar. Curiously, once you do that, videos opened within the same tab will play fine.

We need to redesign this to work around web developer's expectation of a particular state for the video element, or remove this feature. Including our own videodocument, aparently. So we should fix this.

(In reply to Caspy7 from comment #0) > http://video.webmfiles.org/big-buck-bunny_trailer.webm We should fix this part sooner rather than later.

Gerald - can you add this to your queue?

Good timing, I can work on it now.

Another regression bug from bug 659285. I've been thinking we could fix this by either: 1. Adding #ifdef MOZ_WIDGET_ANDROID blocks around the behaviour changes added in https://hg.mozilla.org/mozilla-central/rev/a2ed39faf480 or 2. Split the behaviour changes from a2ed39faf480 out so they're controlled by a separate pref, which the Android UI button to disable autoplay also sets. I looked into this briefly a few weeks back, and it didn't look obvious how to make a checkbox in the Fennec UI control more than one pref. So maybe we need a separate pref which the Android UI sets which means "pretend media.autoplay.enabled is false *and* only honour play() calls from user-generated event handlers".

(In reply to Ralph Giles (:rillian) from comment #2) > We need to redesign this to work around web developer's expectation of a > particular state for the video element, or remove this feature. > > Including our own videodocument, aparently. So we should fix this. Please (!) don't remove the feature entirely - I and many others viewed video autoplay as one of the biggest (now fixed) problems with firefox. Not because of youtube and vimeo, but because of video ambushes from ads and news sites. I think I've noticed this bug as well (ff42 win32). It may be underreported since it bears resemblance with an adblock list issue.

I'm planning to go with option #2 from comment 6, i.e.: Add a new pref that works like the current one to disable autoplay *and* non-user video.play(), for Android's (and efwb001) benefit, and wind back "media.autoplay.enabled" to only mean autoplay. Also I'll look at fixing the internal big-play-button issue when autoplay is disabled (The actual original issue described in comment 0, at least for straight video files).

(In reply to Gerald Squelart [:gerald] from comment #8) > I'm planning to go with option #2 from comment 6, i.e.: > Add a new pref that works like the current one to disable autoplay *and* > non-user video.play(), for Android's (and efwb001) benefit, and wind back > "media.autoplay.enabled" to only mean autoplay. > > Also I'll look at fixing the internal big-play-button issue when autoplay is > disabled (The actual original issue described in comment 0, at least for > straight video files). If you are going to change the name of the pref, please update: https://dxr.mozilla.org/mozilla-central/rev/9a358be6fa798f24deecac1b502742b2c37cd6bd/mobile/android/chrome/content/browser.js#550 when you do.

(In reply to Randall Barker [:rbarker] from comment #9) > If you are going to change the name of the pref, please update: > https://dxr.mozilla.org/mozilla-central/rev/9a358be6fa798f24deecac1b502742b2c37cd6bd/mobile/android/chrome/content/browser.js#550 > > when you do. Consider it done! :-) WIP: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1b0f9ed2c3c Thank you for the tip anyway, and I'll definitely reach to you for feedback&review before I land anything.

(In reply to Gerald Squelart [:gerald] from comment #10) > (In reply to Randall Barker [:rbarker] from comment #9) > > If you are going to change the name of the pref, please update: > > https://dxr.mozilla.org/mozilla-central/rev/9a358be6fa798f24deecac1b502742b2c37cd6bd/mobile/android/chrome/content/browser.js#550 > > > > when you do. > > Consider it done! :-) > WIP: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1b0f9ed2c3c > > Thank you for the tip anyway, and I'll definitely reach to you for > feedback&review before I land anything. I think this change: https://hg.mozilla.org/try/rev/d4218a2eb0e1#l4.12 will require migration for any one who has autoplay disabled in Fennec since this change will re-enable autoplay for them?

(In reply to Randall Barker [:rbarker] from comment #11) > (In reply to Gerald Squelart [:gerald] from comment #10) > > (In reply to Randall Barker [:rbarker] from comment #9) > > > If you are going to change the name of the pref, please update: > > > https://dxr.mozilla.org/mozilla-central/rev/9a358be6fa798f24deecac1b502742b2c37cd6bd/mobile/android/chrome/content/browser.js#550 > > > > > > when you do. > > > > Consider it done! :-) > > WIP: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1b0f9ed2c3c > > > > Thank you for the tip anyway, and I'll definitely reach to you for > > feedback&review before I land anything. > > I think this change: > > https://hg.mozilla.org/try/rev/d4218a2eb0e1#l4.12 > > will require migration for any one who has autoplay disabled in Fennec since > this change will re-enable autoplay for them? If you're looking to migrate a Gecko pref, we have a good place to do that in here: http://hg.mozilla.org/mozilla-central/annotate/324c50cbc40a/mobile/android/chrome/content/browser.js#l1042

(In reply to efwb001 from comment #7) > Please (!) don't remove the feature entirely - I and many others viewed > video autoplay as one of the biggest (now fixed) problems with firefox. Not > because of youtube and vimeo, but because of video ambushes from ads and > news sites. Can you give a little bit more detail about what *exactly* you don't like. Perhaps with some examples. This will help us to come up with a good solution. I don't want to block playback if it causes sites to use animated gifs.

(In reply to :Margaret Leibovic from comment #12) > (In reply to Randall Barker [:rbarker] from comment #11) > > I think this change: > > https://hg.mozilla.org/try/rev/d4218a2eb0e1#l4.12 > > will require migration for any one who has autoplay disabled in Fennec since > > this change will re-enable autoplay for them? > > If you're looking to migrate a Gecko pref, we have a good place to do that > in here: > http://hg.mozilla.org/mozilla-central/annotate/324c50cbc40a/mobile/android/ > chrome/content/browser.js#l1042 Thank you for this information. Alternatively, instead of changing the meaning of media.autoplay.enabled, I could add a new pref that re-enables non-user-script play (default: false on Android, otherwise true). Pros: No pref migration, no surprise to users who do use the existing pref to stop scripts from playing, no (further) change of meaning of existing pref. Cons: Keeps the inconsistency/ambiguity between name and actual effect of 'media.autoplay.enabled'. I'd personally prefer to migrate (so that 'media.autoplay.enabled' only refers to "autoplay" as defined in the HTML specs), but if pref migration and/or annoying some desktop users who use the pref is an issue, I'd be happy to go with the alternative.

Split the straight-video issue into a separate bug: bug 1244592. Looking at the whole mess around media.autoplay.enabled (starting with 5-years-in-the-making bug 659285, and still very much alive with many related open issues: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=autoplay ), I think I will take more time to study this situation before committing to anything that could have unforeseen side-effects. Feedback/comments welcome.

Hi there. I am an engineer on the vimeo video team. We just got a report of this bug from a user. I didn't spend a ton of time digging into it, but when using mediasource for playback the video never starts playing. Segments are loaded into the buffer and you can seek, but even manually calling video.play() from the console will not cause playback to start. It works when playing back a progressive mp4 file. Is there something special we have to do to make playback work (it seems to work on YouTube)? You can test the behavior on our embed test page here: https://player.vimeo.com/embed Thanks

Thanks gerald! @k17e: 1) You're reading text on a webpage, and for some reason Flo if flirting with you from the right margin. 2) You're surfing yahoo news, CNN, or similar while waiting for a meeting to start, and you click on five articles. Unpredictably, one of those articles was a video rather than text, and now everyone in your half of the room is watching. These sites want to feed you video, so they wouldn't consider it a mistake to not give a disclaimer at the link (in other words, it's not their bug). 3) Using mobile, this has bandwidth and battery life ramifications. For those of us with low data limits, these videos make a difference. 4) You open a page from examples 1 or 2, with the sound muted, not intending to view a video. You then open another tab to do something else. It takes ~5 minutes to figure out that this video is the reason why your whole clunky laptop is moderately unresponsive. Or you just blame firefox for being a resource hog (boo). #1 and 2 could be solved by muting videos by default, but this would probably confuse users since they have at least three ways to mute their video (firefox, OS, hardware buttons). media.autoplay.enabled is a good solution/compromise in theory, at least according to the users on the original bug report.

Mass change P2 -> P3

(In reply to iamcraigcampbell from comment #16) > Hi there. I am an engineer on the vimeo video team. We just got a report of > this bug from a user. I didn't spend a ton of time digging into it, but when > using mediasource for playback the video never starts playing. Segments are > loaded into the buffer and you can seek, but even manually calling > video.play() from the console will not cause playback to start. It works > when playing back a progressive mp4 file. > > Is there something special we have to do to make playback work (it seems to > work on YouTube)? You can test the behavior on our embed test page here: > > https://player.vimeo.com/embed > > Thanks I would like to know what do you do while clicking to play.

(In reply to Farmer Tseng[:fatseng] from comment #19) > (In reply to iamcraigcampbell from comment #16) > > Hi there. I am an engineer on the vimeo video team. We just got a report of > > this bug from a user. I didn't spend a ton of time digging into it, but when > > using mediasource for playback the video never starts playing. Segments are > > loaded into the buffer and you can seek, but even manually calling > > video.play() from the console will not cause playback to start. It works > > when playing back a progressive mp4 file. > > > > Is there something special we have to do to make playback work (it seems to > > work on YouTube)? You can test the behavior on our embed test page here: > > > > https://player.vimeo.com/embed > > > > Thanks > > I would like to know what do you do while clicking to play. For dash we do quite a bit depending on what type of “preload” we are using. I suspect the issue is similar to the tap to play on iOS/Android where you have to initiate play on the video element itself quickly. We had to put a workaround specifically for Android DASH to make that work. What we do when the user taps play by default is we create a Promise chain of about 3 or 4 different promises and then after they all resolve we call play on the actual video element itself. In a typical scenario it looks a bit like this: - User clicks on play button - DASH manifest is loaded - MediaSource object is created, src on the video is set to a blob URL, appropriate event listeners are added - Preload segment is downloaded to approximate the user's bandwidth so we can choose a starting video quality - After that, the actual starting segment is downloaded and appended to the SourceBuffer - video.buffered range is checked to make sure we have enough to play after getting an “appendbufferend” event - Play is called on the video element itself

@iamcragicampbell: Over in bug 1277813 I'm making HTMLMediaElement.load() also capture the user intent to play. So if you call load() in the click handler itself on a video element, the video will be blessed and allowed to have playback invoked at a later stage via script. Note you can call load() on a video element without a src attribute or source children or MediaSource attached to capture user intent to play, and only later attach the MediaSource to *actually* load the video. Provided you called load() in the click handler, a later play() will work (once the patch in bug 1277813 makes it into Firefox). So I recommend you create a new video element and call load() on it before setting any source on it in your initial click handler, and ensure that video element is the one you end up attaching your MediaSource and calling play() on later once all your intermediate promises have resolved. Also note, it'll take a few days for the patch in bug 1277813 to make it into Firefox Nightly.

@cpearse: Thank you. I will make this change. Just need to test to make sure it doesn't cause issues anywhere else.

I was finally happy to find a way to disable these idiotic video backgrounds (thanks airbnb, thanks mongodb) from playing on websites, now I'm forced to enable it again because I'm running into this issue. I think this option is a must have. I consider media being played automagically just as intrusive as the possibility to change style of a scroll bar in the past as well as deciding for a user that he is not allowed to remember a password. It's not up to the website builder, but up to the user to decide when media should be played. Is there a fix within sight?

¡Hola Craig! Any luck with this? Just got somebody asking on IRC #firefox about Vimeo being broken with media.autoplay.enabled set to false. ¡Gracias! Alex

Vimeo seems to work for me now on nightly but there are still many sites that are broken because of this setting.

This is broken for http://www.traumaturgyproductions.com/about on nightly. It's a vimeo clip.

@cpearce I just took a look at this and tried what you suggested using Firefox Nightly 52.0a1 (2016-11-04) (64-bit). When I call `load()` on the video element it ends up throwing a `DOMException`, and playback no longer works independent of the flag. I couldn't get more info from FireFox, but playback is broken in Chrome too when calling load on a video element before MediaSource has been attached to it with: DOMException: Failed to execute 'appendBuffer' on 'SourceBuffer': This SourceBuffer has been removed from the parent media source We can probably work around this, but it will be a bit of work cause we may have to change the way our video initialization happens. Do you have any ideas?

@iamcraigcampbell, Perhaps remove the needinfo flag as it may appear to responsible developers that the bug is waiting for additional information while reading the comments it appears to me, this is not the case.

Could everyone vote for this bug please?

In the meantime "Aligorith" has created the autoplay toggle addon which at least lets you play a broken video with a click of the mouse. thanks. (it is claimed that the addon will set autplay on firefox launch to the state it was in when the addon was installed so be in the default state you want before installing it) https://addons.mozilla.org/en-US/firefox/addon/autoplay-toggle/?src=api

Does the the current issue on youtube belong here, or does it have a separate bug that I can't find? There is no large play button, or overlay anymore on youtube. And clicking the video doesn't actually make it play the player just cycles between playing and paused state without the video ever starting playback. If you click the play button, you need to cycle it once, for playback to start. Also you get a notification on the youtube player to restart your device if playback doesn't start in a few seconds. All of this is pretty bizarre behavior.

Under Firefox 52.0 (32-bit), I've discovered that media.autoplay.enabled set to false prevents Pandora (www.pandora.com) from working at all. The "record player" animation spins, but all the controls at the bottom of the page are disabled, and nothing plays (the position of the song being "played" stays at 0:00). As soon as I turned media.autoplay.enabled back to true, Pandora started working.

Since v52 gifv animations cannot be played due to this bug now (media.autoplay.enabled set to false). It was annoying up to this point, but now it's completely broken.

Same problem with Vimeo. If autoplay is disabled, cannot play Vimeo videos.

Hello, I have same problem with media.autoplay.enabled in false on Firefox 52, is there some progress of the issue? On Youtube, there's to press Play button (on bottom bar) twice to play the video On Vimeo, nothing works, the video can't play On webm video, to view videos the same that Youtube, to press Play button twice On Twitter, to view videos and GIFs, the same that Youtube, to press multimedia screen twice

If media.autoplay.enabled is set to false, some Vimeo videos work, such as: https://vimeo.com/55640554 but not others, such as: https://vimeo.com/183181894 Strange...

confirmed. https://vimeo.com/55640554 works while https://vimeo.com/183181894 doesn't tested on ff 53.0.2 and palemoon 27.3.0 (64-bit, ubuntu) (both videos work in chrome even with "Disable HTML5 Autoplay" extension)

I no longer work at Vimeo, but if you scroll up you can see my comments from when I did and when I was trying to fix this issue. Unfortunately, no one from the Firefox team replied to my last comment. The reason some do and some don’t is cause videos using progressive playback will work and videos using MediaSource will not.

In case this can be useful to fix media.autoplay.enabled in Firefox, someone mentioned the FlashStopper add-on. I've tried it, and it seems to work correctly: it prevents videos from autoplaying and doesn't prevent Vimeo videos from working. So, perhaps something similar could be done for media.autoplay.enabled set to false. Note: Contrary to what the name suggests, FlashStopper is not specific to Flash (I don't have Flash installed on my machine anyway).

Is there any progress?

I'll try to fix the vimeo issue in bug1382574.

Hi @gerald, this bug is still assigned to you. Is that accurate, or would it be better unassigned so someone else might pick it up? I see the priority dropped from P1 to P2, and then to P3 due to some mass change about a year ago. Given more users are becoming aware of media.autoplay.enabled and setting it false, due to the race to the bottom by ads for our attention, and that some of us pay per byte of bandwidth, can the priority be reappraised?

Fully agree on this. media.autoplay.enabled is even a nice default setting, IMHO.

Two years and still no fix... we really need the autoplay disable feature to work correctly because so much of the web is littered with incredibly annoying auto-playing video now and it gets worse every month. Sites like Vimeo are especially irritating because they are completely incompatible with autoplay disabled. But even YouTube is still not working well- it stops the auto playing, but when the user clicks on "Play", it doesn't play, it will "pause" the non-playing video, then you have to click on play again to make it play. @ Marc Auslander-> Thanks for the info on https://addons.mozilla.org/en-US/firefox/addon/autoplay-toggle addon, but it says it is not compatible with current versions (55). So that is no longer a help. @ Vincent Lefevre-> Thanks for the info on https://addons.mozilla.org/en-US/firefox/addon/flashstopper which DOES work correctly, regardless of the state of the media.autoplay.enabled setting. And you are right, 99% of people (including me) would overlook it, thinking it is just another Adobe Flash blocker and not effective on HTML5 video.

Unable to reproduce. (videos *will* play, despite my best efforts to keep them from playing) I am strobe-sensitive and need to block most animation, including autoplaying videos, gifs, carousels, and mal-designed websites. I use 3 about:config fixes to block animation, disable all plugins, and use 6 extensions and 10 userstyles to block animation, but autoplaying video still gets through.

(In reply to MarjaE from comment #46) > Unable to reproduce. > > (videos *will* play, despite my best efforts to keep them from playing) > > I use 3 about:config fixes to block animation, disable all plugins, and use > 6 extensions and 10 userstyles to block animation, but autoplaying video > still gets through. Nothing will effectively block "carousels", auto slideshows, fly-ins, scrolling drop-downs, moving objects, and other extremely annoying animations, unless you block all javascript, which will just make all modern sites completely useless. Or unless you have countless hours to waste trying to block specific things for every specific site, which then all falls apart as soon as the site changes. Unfortunately, the days are gone where you could just turn off animated GIF, uninstall Flash, block popups, set marquis and blink tags off, and have a non-moving and peaceful web experience. This thread is specifically about HTML 5 video with media.autoplay.enabled set to TRUE. And the setting does work, it just isn't working well to enable playback on all sites, when desired. Flashstopper seems to do what media.autoplay.enabled can't do properly (block it as well as allow video to play when wanted). Admittedly, I haven't been using it long, but so far so good.

The flashstopper and also the autoplay-toggle extensions are legacy extensions and will not work moving forward so it should be high priority to make this work correctly at the browser level.

"And the setting does work, it just isn't working well to enable playback on all sites, when desired." it isn't working to block video on certain sites, either. e.g. it can't block video from the Huffington Post.

(In reply to MarjaE from comment #49) > e.g. it can't block video from the Huffington Post. If this concerns HTML5 video, you should open a new bug.

(In reply to MarjaE from comment #49) > it isn't working to block video on certain sites, either. e.g. it can't > block video from the Huffington Post. I would never normally visit that site, but for you, I just did. media.autoplay.enabled set to true does block their video from auto playing on every sample page I tried (and that is with the extensions/addons disabled, just to be sure). The only exception, oddly, is when I scroll past the paused video and then scroll back up to it again.... then it starts playing. Only site I have seen that happen on so far. Thankfully, if I re-enable the flashstopper add-on, it stops it from playing when scrolling back up, too. So this actually is an interesting twist in the saga. Whatever flashstopper is doing seems to be the functionality that needs to be baked-into Firefox (or at least always available as an option).

Now this feature has two primary problems, see more details in bug1382574 comment4. First problem is we're blocked by bug1185052, we need some DOM guys to fix it. Second problem is we need to communicate with most video websites. They should modify their code to handle the rejected promise [1] when we don't allow to play the media. [1] http://searchfox.org/mozilla-central/rev/6482c8a5fa5c7446e82ef187d1a1faff49e3379e/dom/html/HTMLMediaElement.cpp#4014

(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #52) > Second problem is we need to communicate with most video websites. They > should modify their code to handle the rejected promise [1] when we don't > allow to play the media. Then we should propose a spec change standardize this behavior (It is possible for user-agents to reject the promise).

¡Hola Alastor! Just wanted to note this can break WebRTC sites. Ended up here again as upon loading https://meet.jit.si/untranslated and allowing both microphone and camera people was able to hear and see me but I got no video nor audio and nothing leading me to let the media play. Would that be a bug on this about:config preference or on WebRTC itself that needs to be more aware of this? ¡Gracias! Alex

(In reply to Masatoshi Kimura [:emk] from comment #53) > Then we should propose a spec change standardize this behavior (It is > possible for user-agents to reject the promise). It has been mentioned in the spec [1]. > If the media element is not allowed to play, return a promise rejected with a "NotAllowedError" > DOMException and abort these steps [1] https://html.spec.whatwg.org/multipage/media.html#dom-media-play (In reply to alex_mayorga from comment #54) > Ended up here again as upon loading https://meet.jit.si/untranslated and > allowing both microphone and camera people was able to hear and see me but I > got no video nor audio and nothing leading me to let the media play. Thank for report! This issue is as same as the first problem I mentioned in comment52, it would also be fixed by bug1185052.

Hello, let me again advocate for a simpler solution. IMO the same way as we prevent pop-ups or handle camera, microphone, location and notifications permission can be utilized for media on the web site. This will make user better aware of what is being enabled, what can be enabled, etc. When we try to automatically figure out whether something is triggered by user or not, there would always be hacks. I found a few websites that let you play some videos. When you click in the player to change size, rewind, set audio or whatever, some of the times it opens annoying pop-ups, sometimes it does what you want. So they are IMO tricking the system into believing it was the user click that triggers the action but in fact this is not user's intention. I described this in bug 1328141. So I still think that presenting a popup to user to confirm play is desired and having a list of available media like the options for enabling mic and camera would be most reliable and clear for the user.

Actually even FlashStopper doesn't work on all videos. In order to be able to play the video at http://futureoffakenews.com/ I must set media.autoplay.enabled to true and disable FlashStopper (i.e. configure it to "allow autoplay" for this web site), in which case the video forcibly autoplays. If I don't disable FlashStopper, I just get the first frame and a spinning wheel. I've looked at the source of the web page. It embeds a YouTube video. If I copy the YouTube URL to the address bar, the video doesn't autoplay, but I can play it by clicking on the play symbol, i.e. everything is fine.

(In reply to Vincent Lefevre from comment #57) > Actually even FlashStopper doesn't work on all videos. In order to be able > to play the video at http://futureoffakenews.com/ I must set > media.autoplay.enabled to true and disable FlashStopper (i.e. configure it > to "allow autoplay" for this web site), in which case the video forcibly > autoplays. If I don't disable FlashStopper, I just get the first frame and a > spinning wheel. I can confirm your findings, unfortunately. Linux 64 bit, vanilla Firefox 55.0.1, I can't get it to play with flashstopper active. Ug, nothing can be easy.

I believe at one point there is little FireFox can do. So, what may be broken is the site, not the browser. The fact of the matter is that disabling autoplay is a feature only "advanced" users tend to set and many sites won't care if their site misbehaves in this circumstance. Remember, you are initially warned regarding changes made via "about:config". Ultimately by disabling autoplay the user is, in a way, wrestling control away from the site author/developer and so the nature of the problem becomes political rather than technical. Anyway, just a 2 cent contribution to the discussion.

@ReliefCrew, Problem is not political. Browser is user application. It should serve user's needs. To have good UX, user should be able to control how different functionality of that app works. Reasons control is needed wrt media auto-playing might be various and a lot of them have been already listed above. Nothing political and also no reason to help webmasters' hidden agendas. The option is presently experimental, that's why it is only enabled through `about:config`. Intention is to have it enabled by default when it is stable. Advanced users have tested the option and have figured out different flaws in its implementation. That's this bug all about. In light of latest comments, it appears to me that making browser make the correct judgement automatically would not be feasible. IMO Firefox should present to the users similar controls to web-rtc mic, camera and screen sharing requests. It would be consistent - be it media playback or capturing - it's very similar.

@ReliefCrew It's not a political issue to wrest control away from the site developer in the case where they're essentially clickjacking to autoplay videos (I just mean they're pretending the user requested the video to play, but the analogy is solid). It's a (minor) security issue. I'm sure it's only occasionally malicious, but it's still Firefox's non-political responsibility to provide sites with legitimate ways to do anything they should be allowed to do, while providing them with reliable errors when they try to do anything they aren't allowed to do. It seems like the right approach, which has been proposed before, is to adjust the API so that sites have a right way to try to play a video any time they want, and to know if their request was rejected. Then this bug is resolved and it's a broken site's bug when they ignore exceptions, not Firefox's. @Alastor Wu Is it still true that once the DOM bug1185052 is fixed, you can add a "notallowederror" and the bug is resolved? Is the DOM bug1185052 going to be fixed? Just wondering why people are still proposing new solutions if a perfectly good one is underway. If there's an insurmountable obstacle, what do you need from the community?

Well, no one has to agree... that's certainly true! It does seem that bug1185052 is far less ambiguous. Perhaps political isn't the exact right word and the overarching issue is simply more subjective than anything else. Especially because, for all the reasons mentioned in comment 17 (and contrary to the title of this bug), I think my personal user experience is actually _enhanced_ when media.autoplay.enabled set to false :-) At least at the present moment. OTOH, as a web-developer who might want to walk a thin line of click-baiting and/or feeding propaganda and advertisements to users, I might not feel the same way. Depends on which side of the bed one wakes up I guess. The only things that seem sure are that I'd like to see the media.autoplay.enabled option remain and am hopeful that future versions (perhaps due to resolution of bug1185052) will help balance my schizophrenia.

What about providing users with legitimate ways to protect ourselves? Web accessibility depends on users being able to configure sites to work with our needs-- whether to block strobing lights and other animation, or to work with screen readers, or to work with scrolling software, or whatever else. https://www.abilitynet.org.uk/news-blogs/why-autoplay-accessibility-issue

(In reply to efwb001 from comment #62) > @Alastor Wu > Is it still true that once the DOM bug1185052 is fixed, you can add a > "notallowederror" and the bug is resolved? Is the DOM bug1185052 going to be > fixed? Just wondering why people are still proposing new solutions if a > perfectly good one is underway. If there's an insurmountable obstacle, what > do you need from the community? We will fix the pref "media.autoplay.enabled" once the bug1185052 got fixed, it means that the pref won't break any website user experience (ideally) when it's open. The implementation would be done in bug1382574.

Will this give any possibility to address Bug 1182329 - not possible to use WebRTC when media.autoplay.enabled = false? Because the pref breaks the user experience for any videoconferencing website.

How does this tool do it? https://addons.mozilla.org/en-US/firefox/addon/enhancer-for-youtube/

I'm experiencing the same issue with netflix in firefox 56 on windows 10. White listing would be an acceptable workaround but I think it's not available? The experience with netflix media.autoplay.enabled false is that instead of the videos playing the window (or full screen) is just black, and there is no button or right click context menu to play.

Confirmed on Firefox 56.0 (64-bit) on Windows 10. The behavior is a bit "all over the place". For example, on YouTube I can get the videos to play only after I manually advance the video using the player's timeline bar, then hit "play". Hitting "play" alone will not play the video unless I manually advance it first by a small amount. Vimeo is completely broken when "media.autoplay.enabled" is set to false. The video itself will actually "play" if you manually scroll through the timeline bar, but unlike YouTube, it will not actually play by itself at all when you advance it a bit and hit "play". The video itself and the player's controls show up as expected, it just won't actually play.

I would like to add that I just upgraded to Firefox 57, so I lost the ability to use FlashStopper. I decided to try media.autoplay.enabled=False again. I am happy to report that so far, I have had no problem with Vimeo or Youtube, although on some I still have to press play on the control bar, clicking on the video doesn't work... very minor. On another site, I still had to do the play-pause-play to get it to play. Have only been using it for several hours, but so far it is not horrible. I am not sure if the sites are changing, or additional work was done in recent versions of Firefox, or both, but I am liking the outcome. BTW- Firefox 57 is FAST! :)

(In reply to crxssi from comment #70) > I would like to add that I just upgraded to Firefox 57, so I lost the > ability to use FlashStopper. I decided to try media.autoplay.enabled=False > again. I am happy to report that so far, I have had no problem with Vimeo > or Youtube, although on some I still have to press play on the control bar, > clicking on the video doesn't work... very minor. On another site, I still > had to do the play-pause-play to get it to play. Have only been using it > for several hours, but so far it is not horrible. I am not sure if the > sites are changing, or additional work was done in recent versions of > Firefox, or both, but I am liking the outcome. > > BTW- Firefox 57 is FAST! :) Thanks for this comment! We are trying to provide the best user experience and will post our block autoplay policy once we finalize the UX part.

Confirmed on 57.0 Same as Patrick S Youtube requires multiple "play" hits Vimeo will not play at all but will advance via clicking the video position bar.

(In reply to MKay18 from comment #72) > Confirmed on 57.0 > Same as Patrick S > Youtube requires multiple "play" hits > Vimeo will not play at all but will advance via clicking the video position > bar. Firefox 57.0 under Linux: Vimeo plays correctly with a single click on the "play" button on the bottom controls. It will not play if you just click on the body of the video window. Once it is playing, play/pause works also by clicking on the body of the video window. Youtube acts exactly the same way. A single click on the "play" button on the bottom controls will play. Once it is playing, play/pause works also by clicking on the body of the video window. I don't know why the behavior could/would vary from one user to another, unless it is because I also block ads with uBlock Origin? I did find a site yesterday that was nothing but a video and it would not play and had no shuttle control or bottom controls at all. The ONLY way I could play it was to set media.autoplay.enabled to true and reload the page.

Ug. I found another problem with media.autoplay.enabled = false, Spotify's web player. With it set to false, it won't play any music. It acts like it wants to play, but doesn't (no sound and no movement of player timeline). You HAVE to set it to true for the music to actually play the music. Very annoying. At a very minimum, I wish there was at least a control/button we could put on the UI somewhere so it could be turned on/off easily...

(In reply to crxssi from comment #75) > Ug. I found another problem with media.autoplay.enabled = false, Spotify's > web player. With it set to false, it won't play any music. It acts like it > wants to play, but doesn't (no sound and no movement of player timeline). > You HAVE to set it to true for the music to actually play the music. Very > annoying. At a very minimum, I wish there was at least a control/button we > could put on the UI somewhere so it could be turned on/off easily... If you're using Nightly, you can set the pref "media.autoplay.enabled.user-gestures-needed=true". It's our new experience feature and can fix those issues. In addition, it would become default behavior for blocking autoplay in the furture.

(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #76) > If you're using Nightly, you can set the pref "media.autoplay.enabled.user-gestures-needed=true". > It's our new experience feature and can fix those issues. Thanks for the information. I can find no documentation about this new pref, other than bug 1415478 and bug 1382574, which say "Muted media can always be autoplay even the pref "media.autoplay.enabled=false"." It sounds like you are saying that with "media.autoplay.enabled.user-gestures-needed=true" it will allow auto playing of video, it is just muted. Your first post in that bug says "Since muted autoplay media won't annoy user, so we should allow them to play." And that is a 100% false statement. Reading through THIS bug, you can see that many people are just as annoyed by the video as the audio. To me, it is even WORSE when audio is playing, but muted autoplaying video is still horrible. Unwanted/unrequested video is extremely visually distracting.... that is on top of wasting CPU, battery, and bandwidth. > In addition, it would become default behavior for blocking autoplay in the future. Now I am just even more nervous. It sounds like Mozilla is now preparing to ruin "media.autoplay.enabled" by copying the way Chrome does it: https://sites.google.com/a/chromium.org/dev/audio-video/autoplay They allow muted playback of video! This is very bad. They allow ANY media to play if the user clicks on ANYTHING on the web page! This is very bad. I am now extremely distressed/upset at the prospect of Mozilla REMOVING media.autoplay.enabled and replacing it with media.autoplay.enabled.user-gestures-needed, which does not address what many users, me included, want. I understand this is a complicated issue, but changing the goal doesn't fix the problem. :(

(In reply to crxssi from comment #77) > Your first post in that bug says "Since muted autoplay media won't annoy > user, so we should allow them to play." And that is a 100% false statement. > Reading through THIS bug, you can see that many people are just as annoyed > by the video as the audio. To me, it is even WORSE when audio is playing, > but muted autoplaying video is still horrible. Unwanted/unrequested video > is extremely visually distracting.... that is on top of wasting CPU, > battery, and bandwidth. Yes, and I would say that this is even worse: since it is muted and the video is not visible, one may not notice that it is playing. This can silently cost money.

(In reply to Vincent Lefevre from comment #78) > Yes, and I would say that this is even worse: since it is muted and the > video is not visible, one may not notice that it is playing. This can > silently cost money. If I understand what is planned, you WILL be able to see the silent video playing, no matter what you do and we will have no way to automatically prevent it from starting, the moment the page is loaded. I think what you are saying is that the video would play even on a region of the current page that might not be currently visible at that moment (scrolled off)- if that is what you mean, yes, that is also true. Once the user interacts with the page in any way, it will then suddenly unmute the already playing video element (if there is one).

Why do we need another pref here? "media.autoplay.enabled.user-gestures-needed=true" seems overkill. Will you be removing "media.autoplay.enabled"? Otherwise there are overlapping preferences that contradict each-other. It would seem ideal that "media.autoplay.enabled" should remain as the sole pref, and will not allow auto-playing of videos AT ALL. People still do have bandwidth constraints (besides the obvious factor of not wanting videos to auto-play from an annoyance standpoint). "media.autoplay.enabled","false" should do what it says. Don't auto-play anything, even without the audio, until the control is manually interacted with.

(In reply to crxssi from comment #77) > Now I am just even more nervous. It sounds like Mozilla is now preparing to > ruin "media.autoplay.enabled" by copying the way Chrome does it: > https://sites.google.com/a/chromium.org/dev/audio-video/autoplay > > They allow muted playback of video! This is very bad. Well, we will do something similar like Chrome, but it won't be the same. For the blocking policy, we will provide different options for user, the default one is blocking all audible media and allow non-audible media (and per site setting for the exception), others are blocking all media (like what we have now) and allowing all autoplay media. > They allow ANY media to play if the user clicks on ANYTHING on the web page! > This is very bad. We will also do that, if the page has been interacted by specific user gestures, we will allow this page to autoplay. For more details, you could wait for our UX spec (In bug 1420389, and the spec will come out soon) (In reply to crxssi from comment #79) > Once the user interacts with the > page in any way, it will then suddenly unmute the already playing video > element (if there is one). No, we allow the non-audible media, not muting the audible media. If the media is audible, it won't be allowed to autoplay. (In reply to Patrick S from comment #80) > Why do we need another pref here? Because it's an experimental feature, and we don't want it to replace the current feature now.

(In reply to Alastor Wu [:alwu][please needinfo me][GMT+8] from comment #81) > We will also do that, if the page has been interacted by specific user > gestures, we will allow this page to autoplay. For more details, you could > wait for our UX spec (In bug 1420389, and the spec will come out soon) > [...] > No, we allow the non-audible media, not muting the audible media. > If the media is audible, it won't be allowed to autoplay. > > (In reply to Patrick S from comment #80) > > Why do we need another pref here? > > Because it's an experimental feature, and we don't want it to replace the > current feature now. Thanks for the additional information, again. I have added myself to follow bug 1420389 and look forward to a more detailed description of how it might operate (because it is unclear there). If you can't already tell, I am not a fan of allowing video to play automatically, muted or not, unless the user specifically asks for it. But if the user is given choices about how the blocking policy work, that will help a lot. Also relieved that the new preference will not replace this one (although far from perfect, what we have now at least is tolerable). I might have "jumped the gun" a bit on my comments, but I have seen Google Chrome feature copying before, and often I think Google takes completely the wrong approach (especially with lack of user control and customization). I appreciate your continued work on these issues.

Firefox 57 on Mac OS 10.10.2 - same as others - autoplay enabled false breaks vimeo - no way to play video even after multiple clicks on the play bar, although one can advance the vid

(In reply to crxssi from comment #82) > Thanks for the additional information, again. I have added myself to follow > bug 1420389 and look forward to a more detailed description of how it might > operate (because it is unclear there). If you can't already tell, I am not > a fan of allowing video to play automatically, muted or not, unless the user > specifically asks for it. But if the user is given choices about how the > blocking policy work, that will help a lot. Also relieved that the new > preference will not replace this one (although far from perfect, what we > have now at least is tolerable). I might have "jumped the gun" a bit on my > comments, but I have seen Google Chrome feature copying before, and often I > think Google takes completely the wrong approach (especially with lack of > user control and customization). I appreciate your continued work on these > issues. Thanks for your feedback. We like to hear any feedback. Currently, we are using this two prefs [1][2] for experiments and tests. Our autoplay policy (bug 1420389) has not finalized yet. We may adopt some good ideas from Chrome but as far as I can tell right now, our policy would be different from them. [1]media.autoplay.enabled [2]media.autoplay.enabled.user-gestures-needed=true

https://addons.mozilla.org/de/firefox/addon/disable-autoplay/ adds some functionality the way I expect it for HMTL-5-Video. One can chose per site, whether it should be auto-started and/or preloaded. That should be built-in for all types of media!

(In reply to michaelspohn from comment #85) > https://addons.mozilla.org/de/firefox/addon/disable-autoplay/ adds some > functionality the way I expect it for HMTL-5-Video. One can chose per site, > whether it should be auto-started and/or preloaded. That should be built-in > for all types of media! that extension is fantastic, exactly the control I would expect to have

(In reply to michaelspohn from comment #85) > https://addons.mozilla.org/de/firefox/addon/disable-autoplay/ adds some > functionality the way I expect it for HMTL-5-Video. One can chose per site, > whether it should be auto-started and/or preloaded. That should be built-in > for all types of media! English site: https://addons.mozilla.org/en-US/firefox/addon/disable-autoplay/ Reviews: https://addons.mozilla.org/en-US/firefox/addon/disable-autoplay/reviews/ It does look extremely interesting, although the reviews are all over the map, resulting in a 3 star rating (however, those reviews are across ALL versions of the addon). Some of the scores and reviews are incorrect (but that is inherent with most any review/scoring system). I installed it myself to test it. First- you MUST turn on media.autoplay.enabled in config or that will override the addon!! It gives a nice control icon/button, with menu. It does seem to work. By default, it disables autoplay on the sample sites I visited. And there is a per-domain preference in the extension/addon config preference page. When I told it to allow youtube.com, that ended up in a list and it remembered. Conversely, it doesn't seem to interfere with playback on Spotify, like using media.autoplay.enabled=true does, even when I had NOT whitelisted Spotify. When it blocks playback, it has some of the similar issues we have seen with just using media.autoplay.enabled. For example, on sites like cnn.com [yeesh] you have to play/pause/play to get it to play the video. But because this can control things on a per-domain basis, it is FAR more powerful than media.autoplay.enabled. So it seems like it is suitable replacement for the sorely missed "Flashstopper" addon. Better because it has more controls and per-domain, yet still a little more flaky, but no worse than using media.autoplay.enabled. Thank you very much for sharing the information about the Addon. I am not sure how I/we missed this addon when searching in the past, it has been available since October 2016, perhaps because it doesn't say "video" anywhere. I will continue to use/test it and see how it goes. I have Emailed the author thanking him and letting him know about this thread.

Just want to second that I still have the below issue in latest Firefox and add a vote for devs to look at this, as this has been a problem for a few months. Fixed it by randomly switching about:config settings to default until I hit the right one. Hopefully this will appear in search results for the next person running into this. Netflix video doesn't play, though shows thumbnail and can be scrolled through, when media.autoplay.enabled is set to false. I think it's been messing up some other videos too, like Vimeo and Twitter. Youtube runs fine for me. I love how it prevents videos from autoplaying on many sites, but breaking functionality entirely makes it not possible to use. I will try the add-on. (In reply to lundberj from comment #68) > I'm experiencing the same issue with netflix in firefox 56 on windows 10. > White listing would be an acceptable workaround but I think it's not > available? > The experience with netflix media.autoplay.enabled false is that instead of > the videos playing the window (or full screen) is just black, and there is > no button or right click context menu to play.

Just to add, google music experience is also broken. The UI thinks the music is playing, but in fact the firefox still waiting for user to activate content.

https://de-vid.com also seems to be broken

(In reply to thatotherdudeishere from comment #90) > https://de-vid.com also seems to be broken But it does work great with "Disable HTML5 Autoplay" https://addons.mozilla.org/en-US/firefox/addon/disable-autoplay

This add-on also doesn't work when autoplay is disabled https://addons.mozilla.org/en-US/firefox/addon/worldwide-radio/

I hope this is not another Firefox bug/problem with a track record of several years that's not going to be fixed until the next complete refactor (of the "..." engine). :o Thankfully extensions and userscripts can work around zillion issues, including this one. As for the actual problem: it's still present today with youtube. Environment: HW: Dell Latitude 5480 OS: Ubuntu 18.04.1 (all available updates installed) Firefox (OS package): 61.0.1+build1-0ubuntu0.18.04.1 Tested in a brand new user profile. Only setting changed after profile creation: media.autoplay.enabled = false Test URL: https://www.youtube.com/watch?v=RWumR_Nu8Ww Reloading the URL several times ends with mixed results: sometimes the video is stopped properly, a big YT play button appears in the center of the video thumbnail image and clicking it will start playback. Other times the video does not actually play (frozen image), but the play button in the bottom-left of the control bar shows the "pause" button, which means it's in playing state. Toggling this button between play and pause states does nothing at this point. The video cannot be forced to actually start playing.

This should be fixed on Nightly now with new block autoplay behaviour.

(In reply to Chris Pearce (:cpearce) from comment #94) > This should be fixed on Nightly now with new block autoplay behaviour. Thanks for the information. Would you be able to point us somewhere was to what this new behavior will be? If it acts as described in comment 77 (allowing muted video to autoplay) I would consider it still broken...

Quantum 61.0.1 Mac 10.11.6 Bug still present. To reproduce: 1. Set media.autoplay.enabled to FALSE 2. On youtube.com, go to the specific URL of any video 3. Click on the middle of the screen, NOT the start arrow in the bottom left. Result: The video will flash a bit and the loading bar will move a little bit, but the video will not start. After a while you tube throw up a message suggesting you reload the page. Next: Click on the video start arrow in the lower left of the video. The video will now start and stop normally when you either click on the screen or the arrow/pause button in the lower left. The same behavior can be observed on vimeo.com videos.

(In reply to Chris Pearce (:cpearce) from comment #94) > This should be fixed on Nightly now with new block autoplay behaviour. in addition to the autoplay policy (which should be the default) there should be an option that disables autoplay entirely (disabled by default) -- should another issue be opened for this? I feel like it was the original intent of this bug already

crxssi's deleted comment stated that muted videos would still play and this can't be stopped. That's not acceptable as some of us pay for bandwidth by the byte and can't afford unwanted videos to play unnoticed.

...and some of us have focus issues. I run with media.autoplay.enabled set to false, toss any sites that just refuse to work into a copy of Chrome I keep kicking around, and I'm still trying to find a good "GIF and APNG start without animation and it can be toggled on an image-by-image basis" extension to reconcile my blend of ADD and Asperger's syndrome with post-legacy Firefox.

(In reply to Ralph Corderoy from comment #98) > crxssi's deleted comment stated that muted videos would still play and this > can't be stopped. I would like to know why my comment was deleted and what other comments might have been deleted. Why not delete reply 79 and 82 also, and yours and others which all relate back to objecting muted video autoplaying? If there was a better place to post it, I would have been glad to (or starting a new bug); but having a comment just deleted, with no feedback or direction, when I spent a lot of time researching it and wording it, and I don't have a copy of it now, is not really productive for anyone. > That's not acceptable as some of us pay for bandwidth by the byte and can't > afford unwanted videos to play unnoticed. Or are annoyed by the animation, or the CPU usage, or the slow loading, or associated battery drain. I thought the whole point of having the media.autoplay.enabled setting available, was to allow the user to prevent or allow autoplaying, not to always allow autoplay and have an option to just stop some of it.

(In reply to crxssi from comment #100) > (In reply to Ralph Corderoy from comment #98) > > crxssi's deleted comment stated that muted videos would still play and this > > can't be stopped. > > I would like to know why my comment was deleted and what other comments > might have been deleted. But which deleted comment? All comments seem to be there.

(In reply to Vincent Lefevre from comment #101) > (In reply to crxssi from comment #100) > > (In reply to Ralph Corderoy from comment #98) > > > crxssi's deleted comment stated that muted videos would still play and this > > > can't be stopped. > > > > I would like to know why my comment was deleted and what other comments > > might have been deleted. > > But which deleted comment? All comments seem to be there. Yeesh. I wish I could edit my above postings. Now I see what happened... I asked Chris Pearce (:cpearce) in comment 95 on this bug about the new behavior. My error is that he responded to me, indirectly on a different (but related) bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1420389#c5 and I responded THERE, not here. Then got confused when Ralph Corderoy mentioned my posting was deleted and I, too, believed it disappeared (when it was really on another bug)! I apologize for this mistake, nothing was deleted. This was my response portion (which you can see on the other bug): --------- "Thanks again for the info. [...] here is the answer many might seek: It is utterly broken and will apparently remain that way. All that design and code work boils down to: Firefox *will* allow autoplay if the video is muted, regardless what the user wants. So it is NOT blocking autoplay, it ONLY has options to block unmuted video. It looks like they went OUT OF THEIR WAY, to NOT allow the user to block all autoplaying content! I am extremely disappointed, and I will not be alone." ---------- Again, it might not be appropriate to post that on this bug (depends on how you look at it)... it is actually more appropriate where I did post it, on bug 1420389. Sorry for creating confusion and thanks for helping me figure it out. :)

(In reply to crxssi from comment #102) > I asked Chris Pearce (:cpearce) in comment 95 on this bug about the new > behavior. My error is that he responded to me, indirectly on a different > (but related) bug here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1420389#c5 and I responded > THERE, not here. Sorry, I didn't notice from the emails arriving that we were dancing between two bugs either and so came here and thought it had been removed. Apologies for the spreading further confusion.