Issue metadata
Sign in to add a comment
|
launching chrome app creates un-deletable flash block content setting
Reported by
kgra...@gmail.com,
Mar 13 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. In a new profile, install a new chrome app (e.g. https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb or https://chrome.google.com/webstore/detail/flv-player/dhogabmliblgpadclikpkjfnnipeebjm) 2. Look at chrome://settings/contentExceptions#plugins , notice that an entry has been created for the app id. Even if the app does not use any flash or request any flash content. What is the expected behavior? An entry should not be added to the flash exceptions list. Also, it it should be able to be removed by the user. What went wrong? Whenever a chrome app is launched for the first time, it creates an exception to block flash for that app id, even if that app id makes no use of flash. Also, for an app that does use the flash plugin (in a webview), the app no longer is able to function because the block is immediately active and no longer is able to "prompt (default flash setting)" to run the plugin. This means users must enable flash for all sites to make e.g. https://chrome.google.com/webstore/detail/flv-player/dhogabmliblgpadclikpkjfnnipeebjm function. WebStore page: https://chrome.google.com/webstore/detail/flv-player/dhogabmliblgpadclikpkjfnnipeebjm Did this work before? Yes 55? Chrome version: 56.0.2924.87 Channel: n/a OS Version: OS X 10.12.3 Flash Version: I understand support for chrome apps is going away for osx/mac, but I don't think it's good to start causing apps to create exceptions in the flash window without the user setting it.
,
Mar 14 2017
,
Mar 15 2017
Able to reproduce this issue on Mac 10.12.3 with chrome #57.0.2987.98 and also in earlier version #40.0.2214.0 Attaching a screen-cast for reference. kgraehl@ if this issue works before M55, could you please help us with the expected screen-cast. Thank You...
,
Mar 15 2017
Thanks. I tried with 51, and saw the exception showed up, but it still allowed the webview to embed the SWF. It seems around Chrome 55 or 56 or so, the "Run this plugin" context-menu was removed, and the permission dialog has moved to the URL bar? Maybe for a webview, this type of permission prompt does not become visible but would come in as a webview.addEventListener('permissionrequest') ?
Possibly related:
https://bugs.chromium.org/p/chromium/issues/detail?id=690304
,
Mar 15 2017
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 15 2017
Isn't this just a reflection of the app's content security policy?
,
Mar 17 2017
Unable to reproduce this issue on Mac 10.12.3 with chrome #51.0.2704.63 Attaching the screencast for reference. kgraehl@ could you please provide us with the expected screen-cast of the issue for further triage. Note: Removing the Needs-bisect label, will add once we have steps to reproduce the issue.
,
Jan 22 2018
Mac triage: WontFix old issue without working repro steps. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kgra...@gmail.com
, Mar 13 201762.2 KB
62.2 KB View Download