Add back ability to enabled background-tab autoplay
Reported by
nicspla...@gmail.com,
Dec 9 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Linux; Android 7.0; SM-G955U Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.84 Mobile Safari/537.36 Example URL: Media sites such as youtube Steps to reproduce the problem: DO NIT CLOSE THIS ISSUE WITHOUT PROVIDING A SOLUTION. DO NOT CLOSE THIS WITHOUT PROVIDING A SOLUTION! THE OTHER BUG IS MARKED AS WONT FIX AND THE DEVS REFUSE TO HELP US!!!! PROVIDE A SOLUTION IF YOU ARE GOING TO CLOSE THIS. A long time ago, media opened in a new background tab would automatically play. This was considered desirable by many. One day, a change was made, so background tabs no longer autoplayed and after this, users were given a chrome flag to switch this back to autoplaying media if they wished. Now, with another recent change, the chrome flag was taken out, forcing everyone to have no choice and no means to re-enable the previously existing and desirable behavior. What does all this result in? We can't open stuff that we want to play in the background, without also clicking on the tab to start the media playback. This is very, very annoying, and so detrimental to workflows that users are switching to other browsers, since other browsers don't have this issue. Previous bugs open for similar issues to this have been resolved as won't fix, so I'm opening a bug directly asking for what we want back. I propose either a setting to give us back this desirable behavior where media can autoplay when opened in background tabs, but at minimum include a chrome flag the users can change to bring this back. To be explicitly clear, I am not asking for the flag back. I am asking for a way to re-enable the behavior chrome originally had. Users want this. What is the expected behavior? The new chrome flag introduced that appears to apply to this autoplay policy seems ineffective for this use case. There are no workarounds known. What went wrong? The new chrome flag introduced that appears to apply to this autoplay policy seems ineffective for this use case. There are no workarounds known. Chromium devs keep closing these issues without actually helping. Did this work before? Yes Is it a problem with Flash or HTML5? Both Does this work in other browsers? N/A Chrome version: 62.0.3202.84 Channel: stable OS Version: Any Flash Version: Contents of chrome://gpu: irrelevant. A bug was opened to bring the flag back, and was resolved as wont fix. What is so difficult about giving the users what they want BACK? Give us SOME way to make this work.
,
Dec 9 2017
Explain why this is not getting fixed instead of closing without any words. This used to work as desired, and changes were introduced over time to no longer let us use this the way we want
,
Dec 9 2017
Devs clearly don't care. Prove me wrong.
,
Dec 10 2017
That flag doesn't work. Bugs opened to ask to fix that have been closed as won't fix
,
Dec 12 2017
,
Dec 13 2017
Able to reproduce this issue on reported version 62.0.3202.84 and on latest canary 65.0.3292.0 using Windows 10,Mac 10.13.1 and Ubuntu 14.04 with steps mentioned below. Bisect Info: ========= Good Build: 60.0.3082.0 Bad Build: 60.0.3083.0 Observations: Till 60.0.3082.0 we have gesture-requirement-for-media-playback flag and on disabling it we used to have audio playback on background tabs as well. From 60.0.3083.0 flag is not seen and autoplay policy flag is seen and on enabling/disabling it unable to listen any audio playback on background tab until you navigate to that tab. You are probably looking for a change made after 467781 (known good), but no later than 467782 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/822e6b2520c585093f6fa163b7475bd4dc77dfac..32d29a10153865441252e100a9781648b8df795b Review-Url: https://codereview.chromium.org/2845973005 Suspecting same from changelog. @zmin: Requesting for further inputs on this bug. Thanks!
,
Dec 13 2017
Hi nicsplatts@, Firstly, your issue 787568 is closed because it's a duplicate issue. It's always a better idea to post your request or suggestion in the same thread so that anyone who wants to work on that could find all discussion easily. Secondly, the original issue 728108 is closed as comment#37. Please note that all switches in chrome://flags are used used for developing or testing purpose. These flags are designed to be removed without any notification. In additional to that, if you really want the background tab auto play back. It will be awesome that you could provide more useful information. Many chrome features are based on user feedback. However, a feedback with more details usually helps more. Regards, Owen
,
Dec 13 2017
Assign to mlamouri@ who owns the original issue.
,
Dec 13 2017
I'm not sure how opening another issue will change the outcome of the discussion.
,
Dec 13 2017
@zmin, I don't care that the flags are experimental, this used to be original behavior in chrome. Autoplaying media used to be default. Then, as sc0035 explained, changes were introduced to no longer allow this, but gave us a flag to let us change it back. Now, a new flag replaced that one, and I have no way to get the original behavior back. Now, bugs I open to try to get this behavior back get closed as won't fix, and !mlamouri has failed every single time to provide any solution. Since you failed to provide a fix or solution, I'll go ahead and open a new issue for this. I feel like sc00335 provided more than sufficient information to resolve this.
,
Dec 13 2017
mlamouri@chromium.org explain why you wont fix this. your actions against the group of us who want this fixed is absurd and inexcusable. You keep shutting us down without helping at all
,
Dec 13 2017
Hi nicsplatts, As mlamouri said, blocking background auto play without an re-enable option is a decision made by the developers. Please note that many features in Chromium do not provide any enable/disable option. As I said, if you truly believe that it's not a proper decision, please provide some useful feedback. Opening new ticket or saying "I don't care" is not a useful feedback.
,
Dec 13 2017
I don't know what other feedback I can provide. This change was severely detrimental to my workflow, to the point where i have switched browsers
,
Dec 13 2017
I dont understand why a core behavior can change, and users like me get screwed over, and then we are shut down when we ask to get it back.
,
Dec 13 2017
It's my understanding you guys simply want to not help just to spite me, I fail to see the logic behind annihilating desired behavior, giving us a flag to fix it, then breaking that flag, then refusing to help us when we want that original behavior back. WHat else do you want from me?
,
Dec 14 2017
I have provided my feedback, what say you? Please explain
,
Dec 15 2017
Still seeking a resolution
,
Dec 18 2017
Still seeking a resolution
,
Dec 19 2017
Still seeking a resolution to this. Still waiting for feedback on this, as you asked for it I provided it and now you ignore me.
,
Dec 20 2017
Still waiting for a response
,
Dec 27 2017
please provide any counteracting feedback or input to validate your seemingly baseless decision
,
Dec 29 2017
please provide a fix or solution thanks
,
Jan 3 2018
hi, please prove me wrong thanks
,
Feb 27 2018
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? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 Deleted