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 9 users
Status: WontFix
Owner:
Closed: Nov 21
Cc:
Components:
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 sweetmon...@gmail.com, May 31 2017 Back to list
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.
2. 
3. 

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?

https://bugs.chromium.org/p/chromium/issues/detail?id=544723

Did this work before? Yes https://chromium.googlesource.com/chromium/src.git/+/b125a7be15ab35b07f11bf252da1d52bf1a32e06

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.
 
Cc: dalecur...@chromium.org mlamouri@chromium.org
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.
Owner: mlamouri@chromium.org
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 :
http://www.spiff-radio.org/wpsstm_live_playlist/fip/
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 . https://bugs.chromium.org/p/chromium/issues/detail?id=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, avayvod@chromium.org, 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?
Owner: dalecur...@chromium.org
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!
Cc: -mlamouri@chromium.org dah...@chromium.org
Owner: mlamouri@chromium.org
@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.
Cc: mlamouri@chromium.org
 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. 
#15
"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
Comment 53 by 8odo...@gmail.com, Dec 13 (4 days ago)
That "featured" was really annoying. However that flag fixes it (using --ignore-autoplay-restrictions) https://www.chromium.org/developers/how-tos/run-chromium-with-flags although it may cause other problems as it cancels the block altogether...

Comment 54 by nicspla...@gmail.com, Dec 13 (3 days ago)
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
Comment 55 by sweetmon...@gmail.com, Dec 13 (3 days ago)
Agreed. The --ignore-autoplay-restrictions switch did not work for me when I tried it.
Comment 56 by 8odo...@gmail.com, Dec 13 (3 days ago)
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
Comment 57 by gordie.l...@gmail.com, Dec 13 (3 days ago)
I don't think that flag has the same purpose than the old one, but I can be
wrong.
Anyway I had a try and doesn't work here either.

2017-12-13 17:26 GMT+01:00 8odo… via monorail <
monorail+v2.4182965380@chromium.org>:
Comment 58 by nicspla...@gmail.com, Dec 13 (3 days ago)
Even if that did work, which it's not for me, how would I go about doing that on Mac OS X? 8odo...@gmail.com
Comment 59 by gordie.l...@gmail.com, Dec 13 (3 days ago)
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 <
monorail+v2.3941802266@chromium.org>:
Comment 60 by nicspla...@gmail.com, Dec 13 (3 days ago)
Well unfortunately  mlamouri@chromium.org 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. 
Comment 61 by nicspla...@gmail.com, Dec 14 (2 days ago)
Still no support on this issue?
Comment 62 by sweetmon...@gmail.com, Dec 14 (2 days ago)
Give up. They have decided. They're not going to fix it. You're just wasting your time.
Comment 63 by nicspla...@gmail.com, Dec 14 (2 days ago)
I refuse to give up until the better interest of the user is considered, not the will of the developers.
Comment 64 by nicspla...@gmail.com, Dec 14 (2 days ago)
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.
Comment 65 by nicspla...@gmail.com, Yesterday (44 hours ago)
Still seeking a resolution 
Comment 66 by gordie.l...@gmail.com, Yesterday (44 hours ago)
#metoo

2017-12-15 18:15 GMT+01:00 nicspla… via monorail <
monorail+v2.3941802266@chromium.org>:
Sign in to add a comment