New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users

Issue metadata

Status: WontFix
Closed: Nov 21
EstimatedDays: ----
NextAction: 2017-11-13
OS: Windows
Pri: 1
Type: Bug-Regression

Sign in to add a comment

media not playing in background tabs

Reported by, May 31 2017 Back to list

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.7 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Open media (video, audio) in a background tab.

What is the expected behavior?
The audio/video should play if the chrome://flags option "Optimize background video playback. Mac, Windows, Linux, Chrome OS, Android
Disable video tracks when the video is played in the background to optimize performance. #disable-background-video-track" is disabled.

What went wrong?
This issue seems identical to  issue 544723 . Has the patch lapsed?

Did this work before? Yes

Is it a problem with Flash or HTML5? N/A

Does this work in other browsers? N/A

Chrome version: 60.0.3112.7  Channel: dev
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 26.0 r0

Contents of chrome://gpu: 

Chrome browsers on other machines seem unaffected.
Status: WontFix
Sorry, "optimize background video playback" refers to power savings when playback IS happening, that is disabling video decoding when the video is playing in a background tab.
Deferring video load when opened directly in the background tab could be overridden by "Disable gesture requirement for media playback" flag as described in the issue you linked to.
Feel free to reopen the issue if the flag doesn't work.
My error. Apologies. The "Disable gesture requirement for media playback" seems to be missing in this dev version.
Ah, right, I think it was recently replaced with the Autoplay Policy flag. It should still work if you select the no restrictions option.
Autoplay policy Mac, Windows, Linux, Chrome OS, Android
Policy used when deciding if audio or video is allowed to autoplay. #autoplay-policy

I have selected "No user gesture is required." However, background tabs still do not autoplay.
Status: Assigned
Then the change switching user gesture requirement to autoplay-policy might have broken this behavior tweak. Assigning to Mounir to take a look.
This option should be available in the security options from the address bar.
This is really an annoying problem.
This glitch appears to have migrated to the production release.
Version 60.0.3112.101 (Official Build) (64-bit)
Labels: -Pri-2 M-62 Pri-1
Mounir, can you fix this?
Any news ?
Labels: Needs-Feedback
NextAction: 2017-11-13
I'm not quite sure what is the problem here. My best understanding is that you all were using --disable-gesture-requirement-for-media-playback to disable the background playback blocking. If this is indeed the issue, I don't think this feature was ever meant to be used by end users as chrome://flags are not meant to be settings. However, if you really care about this, you can pass --ignore-autoplay-restrictions which will disable all type of autoplay restrictions including the background playback blocking.

Please, let me know if I misunderstood.
Yes, that's it.
But could this be an option in Chrome ? 
It's a pain in the * for every audio website to not be able to autoplay the next track.
(don't know how Soundcloud manage to do it)
I lost a big slice of my visitors since we can't autoplay anymore.

This should only apply to tabs that have not been playing in the foreground before. "next track" feature should not be impacted by this. If it is, can you give me steps to reproduce and I will have a look?
Of course, have a look at this page :
When tab has not the focus, tracklist do not play next track.
I don't have a problem with autoplaying playlists. Youtube, soundcloud, and Spotify all work in that regard. However, for example, if I right click a Youtube video and select "open link in new tab," it does not play until I visit the newly opened tab. This behavior was a new "feature" to Chrome dev 48.0.2535.0 and a flag was introduced in 48.0.2563.0 to disable this behavior according to  issue 544723 . This flag was removed in dev 60.0.3112.7 and subsequently in production version 60.0.3112.101. The flag "Autoplay policy Mac, Windows, Linux, Chrome OS, Android Policy used when deciding if audio or video is allowed to autoplay. #autoplay-policy" does not have any affect on this behavior, and indeed,, indicated that the flag might be broken. I would like to be able to have the option to autoplay media in new tabs again, or should I consider a different web browser?
re #13: so... the reason this is happening is because some of your playback comes from YouTube iframes that you are injecting in the page and the check we have is per frame. It's working fine when you only use the SoundCloud API.

dalecurtis@, do you remember why this is checking on the specific frame instead of the WebContents except that because the check is on the renderer?

re #14: the behaviour you see is working as intended and the autoplay policy isn't meant to change it. I'm afraid that Chrome can't have an experience tailored to every single use cases :(
I get your point, but it seems asinine that a function that used to exist was taken away and results in a poor user experience. Can I at least request that this option be added back to Chrome?
i agree!
@mlamouri: Yes it's a renderer only check currently to avoid any round trips to the browser. It seems this is a regression as indicated by the summary in c#14. As I submitted the original workaround I believe UX should exist for disabling this functionality if users desire. So the chrome://flags option for autoplay policy should be fixed to include this case. Back to you and +dahlke to make the final call.
 Issue 771304  has been merged into this issue.
for the love of god, please give me back control over  this like I had before. I need autoplay for background tabs
" So the chrome://flags option for autoplay policy should be fixed to include this case."

i know this is a huge request, but the correct behaviour for this would be a popup (like the geolocation popup) asking to allow the website to autoplay stuff
Another prompt (like geolocation or notifications) may be useful. Great for experinced users, but some less experienced users will be confused first/again. I agree with this idea and I'm suggesting to consider it.

... meanwhile please make that bloody flag work again! This is crucial. Thanks
Additionally, the --ignore-autoplay-restrictions switch does not affect the aforementioned behavior. 
"so... the reason this is happening is because some of your playback comes from YouTube iframes that you are injecting in the page and the check we have is per frame. It's working fine when you only use the SoundCloud API."

So you mean that if I inject all the Youtube iframes when the user is on the page, it will work ?
But what if it requires to load 100+ youtube iframes ? Won't it be very heavy in terms of ressources ?

The NextAction date has arrived: 2017-11-13
Would love to see the flag come back so I can turn on the behavior that I've always had before this was changed. Please.
What is "NextAction" ?
Any updates on this? 

Comment 29 Deleted

Comment 30 Deleted

Comment 31 Deleted

Comment 32 Deleted

Comment 33 Deleted

Comment 34 Deleted

eager to see this get resolved, but in the meantime I must switch to [INSERT ALTERNATIVE BROWSER HERE] because the impact this change had on my workflow is detrimental and too frustrating

Comment 36 Deleted

Status: WontFix
As mentioned in #13, Chrome does not intend for chrome://flags to be user facing options and is meant for testing/experimenting with features. Blocking playback until a tab was focused is a feature of Chrome for which we do not intend to have a user facing setting.

The issue with the radio website injecting iframes is something worth opening another bug for, however.
So what is the recommended workaround to achieve the desired behavior of how the browser used to work? Not intending flags to be user facing seems like a flimsy argument when there was a flag that did exactly what I want. Call it a setting if nomenclature is all you're worried about.
This is REALLY disappointing.  Guess I've just to put a HUGE POPUP on my website to tell visitors to use another browser.
Are you kidding me? Why not give us the freaking ORIGINAL behavior back instead of taking it from us, then taking the ability to enable it.

I would like to hear what I'm supposed to do to workaround this nonsensical behavior
@mlamouri unacceptable without a work around
Regardless of the "flags being experimental and not intended to be user facing" none of us are fighting that, we are fighting for the fact that, at one point, the default behavior was autoplaying media. Suddenly this changed to default not play, but a flag was introduced to switch this behavior.

Now, you want to change the default behavior, take away our flag to change it back, and tell us no way how to get this back??
1/2 year and no solution... Is it really that hard to just do your job and fix something that is broken? We don't wanna to be a standard option but to be an option in the flags for developers. Removing this feature is pushing me one step away from chrome... Edge doesn't have this problem.
@bob no other browser I've tested (firefox, IE, edge, opera, and old versions of chrome) has this issue, it's purely a code change on chrome and I cannot get anyone to reverse this change or add a way for us to get the old behavior back
Opera has this issue too (at least the developers versions).
We still want this fixed!
 Issue 787568  has been merged into this issue.
What a load of bs. Give us a fix
What is the workaround

Comment 51 Deleted

Comment 52 Deleted

That "featured" was really annoying. However that flag fixes it (using --ignore-autoplay-restrictions) although it may cause other problems as it cancels the block altogether...

I will have to try it again, since it's never worked the way you described. Media never autoplayed no matter what that flag was set to, which is unlike the behavior of the previous autoplayed flag
Agreed. The --ignore-autoplay-restrictions switch did not work for me when I tried it.
I don't know guys, I just followed those instructions. I added --ignore-autoplay-restrictions to my chrome.exe and it worked (I also have Autoplay policy --> No user gesture required) ... Windows 10 Pro, 64. Chrome Version 62.0.3202.94
I don't think that flag has the same purpose than the old one, but I can be
Anyway I had a try and doesn't work here either.

2017-12-13 17:26 GMT+01:00 8odo… via monorail <>:
Even if that did work, which it's not for me, how would I go about doing that on Mac OS X?
Anyway no one regular user will do that complicate trick to surf a website.
We need something easy to use for visitors.

2017-12-13 17:27 GMT+01:00 nicspla… via monorail <>:
Well unfortunately refuses to help us at all, they will continue to close these issues as wont fix and screw us who want this back, all while not giving us any alternative solution.

I will keep opening new issues until this is resolved if I have to. 
Still no support on this issue?
Give up. They have decided. They're not going to fix it. You're just wasting your time.
I refuse to give up until the better interest of the user is considered, not the will of the developers.
Comment #15: "I'm afraid that Chrome can't have an experience tailored to every single use cases :("

It can, and very easily. Simply give us back the original autoplay behavior, or fix the flag you gave us when you took that behavior away, or make the new autoplay policy flag effective.

I don't see what the difficulty int his is, unless this is too hard of a task for you to re-implement what was once existing behavior.

You've gone from making both style of users happy, to cutting some out, and telling them to eat it.
Still seeking a resolution 

2017-12-15 18:15 GMT+01:00 nicspla… via monorail <>:
Removing the 'Disable gesture requirement' was a really stupid choice. It effectively breaks Youtube playlists. It's like Google wants me to switch to one of their competitors?
Nic - I really appreciate your persistence with this. This has annoyed me for months too.
@67 I will keep this up until it's fixed. 

@mlamouri listen to the users, and fix this. We are still waiting and I'm happy to continue asking you for the rest of your chromium developer life.
:) we all will continue to ask over and over and over and over again until we get what we all ask for. 


we suggest listening to the users!!!!
I am still seeking a resolution, whether it is to bring back the flag, or make the existing one effective, or bringing back the original autoplay by default behavior.

...or update the Youtube API.

2017-12-19 18:32 GMT+01:00 nicspla… via monorail <>: still waiting for any input. No one who calls them self a real developer would pull this act on their users. 

We'll be here when you want to consider us!
Would be nice if the flag actually functioned as designed, or if the auto-playback was reverted to previously.
Merry christmas. fix this
hi please fix thanks
please provide a fix or solution thanks
still waiting
I think for google this isn't bug, they want this behaviour
I can't find a perspective where this isn't a bug or desirable behavior. The flag is ineffective so it screws a large portion of users who liked autoplaying. Even before the flag, it was default behavior to autoplay. Why change it and take away the user's ability to tweak it back?
Still waiting to be proven wrong my mlamouri. I see more and more bugs being opened asking for this to be fixed and they are stopping any progress
Still waiting to see this fixed
Does anyone have a workaround for this, it's really annoying that I can't just effortlessly listen to YouTube in the background anymore...

Comment 83 Deleted

>breaks autoplay
>breaks the flag
>says its for the best use case
>breaks youtube preventing more than one video simultaneously playing (like, what? seriously you claim not having autoplay is for the best then this happens??)
>tells users they are screwed
>offers no support or workaround
>closes all the bugs from people asking for this back

gg mlamouri, stellar 
Nothing grinds my gears more than feature regression. We've had autoplay since the incarnation of chromium and now its removed with absolutely no way to reactivate it. Completely screwing with a lot of peoples user flow and any mention of it is being suppressed. I can't help but think this is some sort of ploy to increase ad impressions.
hi i opened a new bug cause there seems to be enopugh demoand to fix this vote here  bug 816547 

Comment 87 Deleted

Do we need Mark Lamourine (mlamouri) to solve this issue? What about to bypass him by someone who cares? Is it possible to track down the original author or piece of code, make a patch or push a PR?

Comment 89 by, Mar 13 (6 days ago)

 Issue 816547  has been merged into this issue.

Sign in to add a comment