Unable to edit Preferences file while Chrome is running. Similarly, no way to dynamically update Preferences
Reported by
e...@securelink.com,
May 12 2016
|
||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36
Steps to reproduce the problem:
1. Launch chrome
2. Edit %localappdata%\Google\Chrome\User Data\Default\Preferences and insert a new file extension into the "extensions_to_open" value (or create and insert an entirely new "download" member, e.g.:
"download":{"extensions_to_open":"securelinkcm"}. Without a known and installed file association this can be still be demonstrated by changing the contents of the extensions_to_open value, and watching that it will be overwritten by chrome.
3. Navigate to a new url (this appears to be when the Preferences file is overwritten but could be triggered in other ways).
What is the expected behavior?
extensions_to_open retains the dynamically configured value, and Chrome is able to launch the given file with the system configured application for that file type without further action by the user.
What went wrong?
The user configured extension is lost when the Preferences file is rewritten. A user must instead manually select "Always open files of this type" in order to launch the given file type automatically.
Did this work before? Yes Versions of chrome circa late-2015
Chrome version: 50.0.2661.86 Channel: n/a
OS Version: Windows 7,8,10
Flash Version:
This is opened as a regression. However, as noted by in https://bugs.chromium.org/p/chromium/issues/detail?id=601586, there is no intent to fix it as a bug. So this might need to be classified as a feature request.
The extensions_to_open is a user preferences, not controlled by a policy, and editing the Preferences files is (loosely) documented as being the method for updating it. See http://www.chromium.org/administrators/configuring-other-preferences
Opening files directly is a common and intuitive way to navigate between a browser and an installed application. Conversely, for an non-savvy user to have to 1) realize there is the "Always open files of this type" option hidden in the unlabelled dropdown menu next to a downloaded file, and 2) to have to take the extra step to do this in order to have a seamless transition to the application associated with the file type, causes a lot of confusion.
Installing an application associated with a file type can be as easy as downloading and launching the app, which then creates the file association and configures the browser to open that file type automatically. Subsequently a user can simply click a link to a file type associated with the app to run. Note that it's a common workflow to do both steps while chrome is running. If the user setting is modified before chrome is launched, it isn't overwritten. But it would be unreasonable to close chrome in order to enable this to work. Configuring user settings is broken by this behavior. Merging the user settings in Preferences instead of overwriting the file would fix this.
,
May 18 2016
Marking the above issue as Untriaged as this is a feature request. Dev Team will take a call on the above request. Thank you!
,
May 20 2016
This is referring to file extensions, not chrome extensions.
,
Nov 2 2017
,
Jan 30 2018
,
Feb 10 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ajha@chromium.org
, May 13 2016