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)
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.
Assignee | ||
Comment 1•6 years ago
|
||
Try setting media.autoplay.enabled.user-gestures-needed=true.
Assignee | ||
Updated•6 years ago
|
Blocks: block-autoplay
Reporter | ||
Comment 2•6 years ago
|
||
This doesn't help.
Reporter | ||
Comment 3•6 years ago
|
||
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 !
Reporter | ||
Comment 4•6 years ago
|
||
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.
Assignee | ||
Comment 5•6 years ago
|
||
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.
Comment 6•6 years ago
|
||
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)
Keywords: regression,
regressionwindow-wanted
Updated•6 years ago
|
tracking-firefox61:
--- → +
Assignee | ||
Comment 7•6 years ago
|
||
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.
Assignee | ||
Comment 8•6 years ago
|
||
Probably a regression from bug 1435133, which landed on 2018-04-10.
Assignee | ||
Comment 9•6 years ago
|
||
(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.
Assignee | ||
Comment 10•6 years ago
|
||
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.
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Comment 13•6 years ago
|
||
Also filed https://github.com/whatwg/html/issues/3635 so the spec can allow us to reject autoplay at this later time.
Assignee | ||
Comment 14•6 years ago
|
||
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)
Keywords: regressionwindow-wanted
Comment 15•6 years ago
|
||
(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 16•6 years ago
|
||
mozreview-review |
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 17•6 years ago
|
||
mozreview-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 | ||
Updated•6 years ago
|
Assignee: nobody → cpearce
Comment 18•6 years ago
|
||
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
Assignee | ||
Comment 19•6 years ago
|
||
(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.
Comment 20•6 years ago
|
||
bugherder |
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
Updated•6 years ago
|
Blocks: 1435133
status-firefox59:
--- → unaffected
status-firefox60:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Updated•6 years ago
|
Flags: qe-verify+
Comment 21•6 years ago
|
||
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)
Assignee | ||
Comment 22•6 years ago
|
||
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)
Comment 23•6 years ago
|
||
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)
Assignee | ||
Comment 24•6 years ago
|
||
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)
Assignee | ||
Comment 25•6 years ago
|
||
Filed bug 1461877 for STR in comment 23.
Comment 26•6 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•