Closed Bug 1453843 Opened 6 years ago Closed 6 years ago

media.autoplay.enabled no longer work on YouTube

Categories

(Core :: Audio/Video: Playback, defect)

61 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla61
Tracking Status
firefox-esr52 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 + verified

People

(Reporter: hub, Assigned: cpearce)

References

Details

(Keywords: regression)

Attachments

(2 files)

In about:config, media.autoplay.enabled is set to false

This is Nightly macOS: 61.0a1 (2018-04-12) (64-bit)

Go to any video on YouTube, from a new tab or window.

It starts autoplaying

Expected:

It doesn't start autoplaying.

On release the problem doesn't happen. Nor did it a few days ago on Nightly.
Try setting media.autoplay.enabled.user-gestures-needed=true.
This doesn't help.
Apparently it works in 61.0a1 (2018-04-12) (64-bit) with the above preference set (and media.autoplay.enabled still set to false).

Thanks !
This is actually weirder. With the same release, I was on the YouTube subscriptions page (the one with your feed). Clicked on a video and it started playing. Not sure what happened for me when I wrote comment #3.
The behaviour we're trying to get to with autoplay is that autoplay is blocked for sites until you interact with the page, and once you've interacted (mouse click, keypress) then we unblock autoplay. This is the behaviour that the media.autoplay.enabled.user-gestures-needed=true controls.

We're also planning on a whitelist, where sites where there's a reasonable expectation that users are at the site to play video will be allowed to autoplay. YouTube would be on that list.
Chris, we got a couple of other reports via Twitter from Nightly users reporting the same issue this week (ex https://twitter.com/persojul/status/986887084827922432) so it's likely to be a recent regression.


Hubert, could you attach your about:support data to this bug please? If you have an hour to spare, would you mind looking for the regression range with mozregression (you can ping me or Usul in the #nightly IRC channel if you need help). Thanks!
Flags: needinfo?(hub)
I saw autoplay blocked in 2018-04-04, and then autoplay not blocked in 2018-04-20, on MacOS Nightly.

Note that we don't officially support media.autoplay.enabled=true on desktop yet, (thought I'm going to try to debug this anyway since I expect it will probably affect the media.autoplay.enabled.user-gestures-needed=true work I'm doing) so I think it's inappropriate to track this for 61.
Probably a regression from bug 1435133, which landed on 2018-04-10.
(In reply to Chris Pearce (:cpearce) from comment #8)
> Probably a regression from bug 1435133, which landed on 2018-04-10.

Confirmed, behaviour changed when bug 1435133 landed.
The problem is that the new path where we block autoplay introduced in bug 1435133 doesn't fire a "pause" event when it rejects the play promise, so YouTube's controls realize the video's paused.

Additionally, even if we're not in a user generated event handler, we unilaterally consider the media element blessed if execution reaches here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#4110
We previously rejected before reaching here when not in a user generated event handler, but now if play() is called before we've reached loadedmetadata, we reject the promise if we're not in a non-event handler and bail out early, and so we'll bless even if not in a user generated event handler. Meaning when we do reach loadedmetadata, we think we were in a user generated event handler when play() was originally called, and so we won't reject the play promise.

I also noted that we manually reject the play promises and then call Pause() here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#5546

But Pause() already rejects the play promises with the same exception here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#5546

So we can remove that redundant reject.
Also filed https://github.com/whatwg/html/issues/3635 so the spec can allow us to reject autoplay at this later time.
hub: I don't think we need your about:support to fix this bug. Thanks for taking the time to file this bug!
Flags: needinfo?(hub)
(In reply to Chris Pearce (:cpearce) from comment #5)
> We're also planning on a whitelist, where sites where there's a reasonable
> expectation that users are at the site to play video will be allowed to
> autoplay. YouTube would be on that list.

This is a terrible idea.  If I set autoplay to disabled, I want autoplay disabled for ALL websites, regardless of what perceived user behavior is.

Even if I'm visiting a website I normally play videos on, I STILL want autoplay disabled on that site until I intentionally initiate autoplay.

There are many times I have multiple tabs open with pages that have video, and do not want those videos playing until I so choose.

There are also times I visit a website to simply read an article, and there is a video I do not care to have playing.  A good example of this is cbsnews.com.  you visit the site and you get videos playing -- even though all you're trying to do is read an article you've clicked on.

If you create your whitelist, presuming user behavior, please also have a master switch and user-configurable whitelist for those users who know what it is they actually want.

Thanks
Comment on attachment 8969554 [details]
Bug 1453843 - Ensure we fire "pause" event when rejecting play() promise.

https://reviewboard.mozilla.org/r/238312/#review244474
Attachment #8969554 - Flags: review?(bvandyk) → review+
Comment on attachment 8969555 [details]
Bug 1453843 - Remove extraneous play promise reject.

https://reviewboard.mozilla.org/r/238314/#review244476
Attachment #8969555 - Flags: review?(bvandyk) → review+
Assignee: nobody → cpearce
Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/37ac866c0cdc
Ensure we fire "pause" event when rejecting play() promise. r=bryce
https://hg.mozilla.org/integration/autoland/rev/6714516bb697
Remove extraneous play promise reject. r=bryce
(In reply to IU from comment #15)
> This is a terrible idea.

Good to know https://twitter.com/chrisryanpearce/status/555282304239562753 still holds true...

We're planning to have UI to allow users to control the whitelist.
https://hg.mozilla.org/mozilla-central/rev/37ac866c0cdc
https://hg.mozilla.org/mozilla-central/rev/6714516bb697
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Flags: qe-verify+
This issue has been reproduced on the following platform: Mac OSX 10.12 on Firefox 61.0a1 (2018-04-11) (64-bit) with the exact same steps as per in the Description.

On Mac OSX 10.12, the issue was verified on Firefox 61.0b3 and it is no longer present. 



However it is worth mentioning that if no AdBlock software is installed,while on Youtube, an Ad will first be displayed;
The Ad will not automatically start, instead it will disappear after the Ad time expires, and when the actual video content is displayed, it does not start to play, but instead you can see buffering progress and an infinite loading animation on the video.

All the while an error message is displayed on the video informing the user that if the content does not start automatically, to refresh the page.

Tapping Play on the video will not render the content to be played, only clicking on a certain time point from within the actual video and the pressing Play will start it. 

Should we open a different ticket for this behavior, or is this a variation of the issue discussed above?
Flags: needinfo?(cpearce)
Vlad, this bug only affects behaviour with Firefox in an unsupported configuration.

We are working towards supporting media.autoplay.enabled=false and media.autoplay.enabled.user-gestures-needed=true, do you see the issue with that configuration?
Flags: needinfo?(cpearce) → needinfo?(vlad.lucaci)
Chris, 
I have tried to reproduce this issue again with the media.autoplay.enabled=false and media.autoplay.enabled.user-gestures-needed=true configuration, and yes, the issue is present only on Mac platform with the exact same repro steps as I described in Comment 21 , but only if there is an Ad displayed at the beginning of the video.

This Youtube video should have an Ad right at the beginning : tinyurl.com/yam6wugf

"If no AdBlock software is installed,while on Youtube, an Ad will first be displayed;
The Ad will not automatically start, instead it will disappear after the Ad time expires, and when the actual video content is displayed, it does not start to play, but instead you can see buffering progress and an infinite loading animation on the video.

All the while an error message is displayed on the video informing the user that if the content does not start automatically, to refresh the page.

Tapping Play on the video will not render the content to be played, only clicking on a certain time point from within the actual video and the pressing Play will start it. "
Flags: needinfo?(vlad.lucaci) → needinfo?(cpearce)
OK, I can reproduce with Nightly on MacOS with those STR.

YouTube's player works in Safari in this case if I remove YouTube from Safari's whitelist, so it may be something we're doing. Will file a new bug for this one. 

Thanks for reporting this Vlad!
Flags: needinfo?(cpearce)
In this case, as the initial issue was indeed verified and fixed, and a new ticket has been created for the behavior of comment 23 then this issue can be closed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.