Issue metadata
Sign in to add a comment
|
re-enable autoplaying media in background tabs, or make user configurable, or make flag effective again
Reported by
nicspla...@gmail.com,
Dec 13 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Example URL: youtube.com Steps to reproduce the problem: Navigate to youtube.com, and open a video in a new tab. Note the video does not autoplay until you click the new tab you've opened. What is the expected behavior? With an effective flag, or a workaround, for media to autoplay when opened in a new tab without gesture input. What went wrong? 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. This change is responsible for the flag being replaced and broken; https://codereview.chromium.org/2845973005 Did this work before? Yes 60.0.3082.0 Is it a problem with Flash or HTML5? Both Does this work in other browsers? Yes Chrome version: 62.0.3202.94 Channel: n/a OS Version: All platforms/versions Flash Version: Contents of chrome://gpu: Understand that I am not necessarily asking for an experimental flag to work. What happened was chrome used to autoplay without any flags, but later flags were introduced alongside the change to no longer autoplay media. When that flag was first created, it let us get the old autoplay behavior back. Now the flag was replaced with the useless current version that is no longer an effective workaround. I seek any sort of workaround, alternative, or anything to get this behavior back. I also need to note chromium bug tracker user mlamouri@chromium.org absolutely should NOT be assigned to this case, as they have proven to repeatedly close this issue as won't fix and refuse to provide us with a solution or any help. I fail to see the difficulty in helping the users get what they want, not what the devs want.
,
Dec 18 2017
This issue is reported many times and marked as wontfix by dev. You can find the bug details here https://bugs.chromium.org/p/chromium/issues/list?can=1&q=reporter%3Anicsplatts%40gmail.com&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids. As CL and obsrvations are already given in https://bugs.chromium.org/p/chromium/issues/detail?id=793607#c7 ,removing Needs-Bisect label. Could someone from Internals>Media team take a look at this issue. Thanks!
,
Dec 18 2017
Thank you for noticing. Many others and myself have provided plenty feedback and demand to resolve this behavior, but as you can see every bug I or others have opened, the dev has closed as wont fix, without providing any reasoning, other than "because I want to" while demanding more feedback from us. When asked to help us with a workaround or a solution or any help, they go silent. When the requested feedback is given, they go silent. Read all the comments in bug 728108 . Clearly we ALL want this behavior back, and a single dev is blocking us with no reasoning provided.
,
Dec 20 2017
On the issues that were closed as wontfix, we have been asking for input from the developers and they have failed to respond or justify why this cannot or should not be fixed. Users continue to ask for this to be fixed with no feedback or support.
,
Dec 27 2017
Merry Christmas everyone. I have still been asking in the other bugs for any feedback that can validate their decision to not fix this, and they still fail to respond. More users continue to ask for this to be fixed. Thank you
,
Jan 3 2018
Kindly still waiting for any assistance : (
,
Jan 11 2018
:(
,
Jan 19 2018
This issue seems to be out of scope for triaging from TE-end as the reporter is asking a specific behaviour to be brought back/re-enable, Hence requesting someone from "Internals>Media" team to have a look into it for further investigation. Adding label TE-NeedsTriageHelp.
,
Jan 22 2018
OP has been (re-)opening bugs for a feature do not intend to support. It was available behind a chrome://flags but chrome://flags are not meant to be used as settings and are not supported features. We had data about the usage of this feature and it was quite low. It wouldn't make sense to add a setting for it product-wise. Especially, seeing that websites were suggesting their users to enable this flag was fairly scary for a feature we never intended to really support.
,
Jan 22 2018
You took away behavior we wanted, then broke the flag. I will keep opening bugs until it's fixed
,
Jan 22 2018
Oh yeah so because a majority doesn't like it we can screw over the people who want it. The fact a larger group didn't use it than a group that did does not justify removing this behavior or ability. Settings exist to give users an option and be happy. You are taking away an ability from a still fairly large amount of users and making them unhappy. You've made me the most unhappy, so I will be here until this gets fixed. Thanks
,
Jan 23 2018
#10 - I strongly advise you not to create more and more issues, because I guess you will be blocked at some point or it will simply be an unnecessary and time consuming (for everyone involved, including you) cat-and-mouse game. Note that Chrome generally caters for the majority. It does not make sense to give budget to develop features used by minorities, or confuse the user with even more options.
,
Jan 23 2018
I will keep creating bugs and some day someone will finally listen If I have to make a vpn and new accounts to keep filing them, I will do so I refuse to let this happen without a fight. Can you clearly not see how important this is? |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Dec 14 2017