diff options
| author | mnissler@chromium.org <mnissler@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-07-15 11:16:25 +0000 |
|---|---|---|
| committer | mnissler@chromium.org <mnissler@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-07-15 11:16:25 +0000 |
| commit | c252240cbdd7d299d59a7bd5ab1edaf409cfa165 (patch) | |
| tree | c519a66af298ca1c372c70244bb6f8608e210fe9 /codereview.settings | |
| parent | 63259a5095c73aafc0e3d84b0e1ba1ef48b05048 (diff) | |
| download | chromium_src-c252240cbdd7d299d59a7bd5ab1edaf409cfa165.zip chromium_src-c252240cbdd7d299d59a7bd5ab1edaf409cfa165.tar.gz chromium_src-c252240cbdd7d299d59a7bd5ab1edaf409cfa165.tar.bz2 | |
allow editing of hompage preferences on Windows, that are not locked by policies
Only disable those homepage-related gui controls, that are explicitly overridden by policies.
This is a different solution than the expected behavior described in the bug below. The main point is that it avoids the ambiguous state, when the user has HomepageIsNewTabPage=true selected, and the policies only specify the HomepageLocation URL.
BUG=46486
TEST=manual
Review URL: http://codereview.chromium.org/2843022
Patch from Gabor Feher <gfeher@google.com>.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52477 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'codereview.settings')
0 files changed, 0 insertions, 0 deletions