media.autoplay.enabled set to false is breaking user experience (videos won't play)

NEW
Assigned to

Status

()

Core
Audio/Video: Playback
P3
normal
2 years ago
3 days ago

People

(Reporter: Caspy7, Assigned: gerald)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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.

Comment 1

2 years ago
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.
Priority: -- → P1
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?
Flags: needinfo?(gsquelart)
(Assignee)

Comment 5

2 years ago
Good timing, I can work on it now.
Assignee: nobody → gsquelart
Flags: needinfo?(gsquelart)
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".
Blocks: 659285

Comment 7

2 years ago
(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.
(Assignee)

Comment 8

2 years ago
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.
(Assignee)

Comment 10

2 years ago
(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?
Flags: needinfo?(margaret.leibovic)

Comment 12

2 years ago
(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
Flags: needinfo?(margaret.leibovic)
(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.
(Assignee)

Comment 14

2 years ago
(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.
Priority: P1 → P2
(Assignee)

Updated

2 years ago
See Also: → bug 1181055
(Assignee)

Updated

2 years ago
Depends on: 1244592
(Assignee)

Comment 15

2 years ago
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.

Comment 16

a year ago
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

Comment 17

a year ago
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
Priority: 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.
Flags: needinfo?(iamcraigcampbell)

Comment 20

a year ago
(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
Flags: needinfo?(iamcraigcampbell)
@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.

Comment 22

a year ago
@cpearse:

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

Comment 23

a year ago
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?

Comment 24

10 months ago
¡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
Flags: needinfo?(iamcraigcampbell)

Comment 25

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

Comment 26

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

Comment 27

9 months ago
@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?

Comment 28

8 months ago
@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.

Comment 29

7 months ago
Could everyone vote for this bug please?

Comment 30

6 months ago
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

Comment 31

6 months ago
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.

Comment 32

5 months ago
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.

Updated

5 months ago
Flags: needinfo?(iamcraigcampbell)

Comment 33

4 months ago
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.

Comment 34

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

Comment 35

4 months ago
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

Comment 36

2 months ago
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...

Comment 37

2 months ago
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)

Comment 38

2 months ago
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.

Comment 39

2 months ago
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).

Comment 40

16 days ago
Is there any progress?
Blocks: 1376321
Duplicate of this bug: 1323063
I'll try to fix the vimeo issue in bug1382574.
You need to log in before you can comment on or make changes to this bug.