| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This moves the syncable/lossy properties of content settings into the
WebsiteSettingsRegistry.
BUG=512683
Review URL: https://codereview.chromium.org/1272583004
Cr-Commit-Position: refs/heads/master@{#343828}
|
|
|
|
|
|
|
|
| |
BUG=399895
Review URL: https://codereview.chromium.org/747953002
Cr-Commit-Position: refs/heads/master@{#343693}
|
|
|
|
|
|
|
|
|
|
| |
We removed the mediastream->camera/mic migration code from content_settings::DefaultProvider, but didn't clean up the associated preference.
BUG=443799
Review URL: https://codereview.chromium.org/1255243004
Cr-Commit-Position: refs/heads/master@{#343651}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a map
The array of managed default prefs which is keyed to ContentSettingsType is
fairly sparsely populated. Rather than have it keyed to ContentSettingsType,
instead create an array which maps ContentSettingsType to the default policy
pref name (similar to what we do for the Allowed/Blocked URL prefs). This
means that when a new content setting is added, this array doesn't need to be
updated.
I did consider adding this to WebsiteSettingsInfo but it seems like the
exception (rather than the rule) to add a new policy pref. Also there are
some inconsistencies which make it hard to do this cleanly, e.g. the
same mediastream pref is used for both camera and mic). I would rather
leave this to a later cleanup.
BUG=512683
Review URL: https://codereview.chromium.org/1276683004
Cr-Commit-Position: refs/heads/master@{#343627}
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the function return type is void so return value not required.
and GetSettingsForOneType() also does not return any value.
Another change is conversion from char* to char array.
BUG=520800
Review URL: https://codereview.chromium.org/1290923003
Cr-Commit-Position: refs/heads/master@{#343357}
|
|
|
|
|
|
|
|
|
|
|
| |
Provider Names and Provider Source are in the form of seprate array.
map usage will make it better readability and maintainability.
BUG= 520352
Review URL: https://codereview.chromium.org/1287943006
Cr-Commit-Position: refs/heads/master@{#343188}
|
|
|
|
|
|
|
|
|
|
| |
This is for arranging the pref names in proper order to get better readability.
BUG=519994
Review URL: https://codereview.chromium.org/1286963002
Cr-Commit-Position: refs/heads/master@{#342994}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replaces
base::StringToLowerASCII(string)
with
base::ToLowerASCII(string)
This form is 1:1 search and replace.
A bunch of places did something like this:
std::string foo(something_else);
base::StringToLowerASCII(&foo);
which became:
foo = base::ToLowerASCII(something_else);
A couple places really wanted in-place changing and they became:
foo = base::ToLowerASCII(foo);
There was pretty trivial cleanup in chrome_main_delegate.cc chrome/test/chromedriver/server/http_handler.cc (fix indenting).
There was more cleanup in:
chrome/installer/util/language_selector.cc and components/plugins/renderer/mobile_youtube_plugin.cc
In components/history/core/browser/url_utils.cc I removed the call since it was calling ToLower on the host name out of a GURL, which is already guaranteed to be lower-case.
NOPRESUBMIT=true
(due to touching code with wstrings)
Review URL: https://codereview.chromium.org/1279123004
Cr-Commit-Position: refs/heads/master@{#342659}
|
|
|
|
|
|
|
|
|
|
| |
This content setting was used for a "Don't ask again" button on the Metro mode infobar, but it appears that got removed at the behest of UI review (https://codereview.chromium.org/23591005) a while ago, so we can remove the setting completely.
BUG=512683
Review URL: https://codereview.chromium.org/1274383002
Cr-Commit-Position: refs/heads/master@{#342572}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
net::FormatUrl and related are specifically concerned with display
policies of URLs, which is not something that //net needs to be aware
of, as that's a UX question.
This folds in net::FormatURL along with the existing //components/url_fixer
and //components/secure_display into a common component,
//components/url_formatter, that handles reformatting URLs for user-friendly
or data storage (url_formatter), for use in security prompts (elide_url),
or for reformatting URLs from user input (url_fixer)
(Disabling presubmit since this is intentionally not fixing a legacy API, just moving it for future cleanups)
BUG=486979
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/1171333003
Cr-Commit-Position: refs/heads/master@{#342445}
|
|
|
|
|
|
|
|
|
|
| |
This moves content setting pref names and their default values into WebsiteSettingsInfo.
BUG=512683
Review URL: https://codereview.chromium.org/1252073002
Cr-Commit-Position: refs/heads/master@{#342045}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to https://codereview.chromium.org/1252973002/. The situation is equivalent:
1. We expect most users to have been migrated from the old preferences, as the migration code has been live for 3 milestones.
2. We can remove the media and cookies migration code, as they are older and the deprecated values could not have made it to the new preferences.
TESTED=Effects on websites in the regular mode and incognito, syncing between two machines
BUG=452388
Review URL: https://codereview.chromium.org/1257093002
Cr-Commit-Position: refs/heads/master@{#341720}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
//components (patchset #16 id:290001 of https://codereview.chromium.org/1171333003/ )
Reason for revert:
breaks gn_check on Android: https://build.chromium.org/p/chromium.linux/builders/Android%20GN/builds/28796/steps/gn_check/logs/stdio
Original issue's description:
> Move net::FormatUrl and friends outside of //net and into //components
>
> net::FormatUrl and related are specifically concerned with display
> policies of URLs, which is not something that //net needs to be aware
> of, as that's a UX question.
>
> This folds in net::FormatURL along with the existing //components/url_fixer
> and //components/secure_display into a common component,
> //components/url_formatter, that handles reformatting URLs for user-friendly
> or data storage (url_formatter), for use in security prompts (elide_url),
> or for reformatting URLs from user input (url_fixer)
>
> (Disabling presubmit since this is intentionally not fixing a legacy API, just moving it for future cleanups)
>
> BUG=486979
> NOPRESUBMIT=true
>
> Committed: https://crrev.com/1659865c3eb47166c82378bb840801135b057a09
> Cr-Commit-Position: refs/heads/master@{#341605}
TBR=droger@chromium.org,jam@chromium.org,mkwst@chromium.org,pkasting@chromium.org,sky@chromium.org,stuartmorgan@chromium.org,felt@chromium.org,rsleevi@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=486979
Review URL: https://codereview.chromium.org/1260033005
Cr-Commit-Position: refs/heads/master@{#341691}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
net::FormatUrl and related are specifically concerned with display
policies of URLs, which is not something that //net needs to be aware
of, as that's a UX question.
This folds in net::FormatURL along with the existing //components/url_fixer
and //components/secure_display into a common component,
//components/url_formatter, that handles reformatting URLs for user-friendly
or data storage (url_formatter), for use in security prompts (elide_url),
or for reformatting URLs from user input (url_fixer)
(Disabling presubmit since this is intentionally not fixing a legacy API, just moving it for future cleanups)
BUG=486979
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/1171333003
Cr-Commit-Position: refs/heads/master@{#341605}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now we have a bunch of arrays lying around the codebase which map
ContentSettingsTypes to various properties of website settings. When a user
adds a new setting, they have to modify each of these maps. We should
consolidate these into a single object which is registered on startup and
contains all properties of website settings.
This CL introduces a WebsiteSettingsRegistry to where website settings are
registered with these properties in WebsiteSettingsInfo objects. Currently
only the ContentSettingsType and string name of the setting are stored.
Two locations in the codebase which previously had separate arrays listing
the string names for each content setting have been changed to use the
WebsiteSettingsRegistry instead.
In followup CLs more properties will be moved into WebsiteSettingsInfo.
BUG=512683
Review URL: https://codereview.chromium.org/1247253003
Cr-Commit-Position: refs/heads/master@{#340651}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The migration of default content settings from one dictionary pref into individual prefs appeared in M43. The next branchpoint is M46. After three versions, it is safe to remove the migration code.
Question: What happens to users who weren't migrated during this time (i.e. jump from M<43 to M>=46)?
Answer: Their content settings will be reset, since their individual prefs will not be populated. However, their profile won't be damaged; the old dictionary will be simply ignored. Thus, the user will have their settings restored to default values, as if in a new profile. For the more sensitive settings, the user will be asked before a permission is granted to the site; however, for cookies, images and javascript the default value is to allow websites to use them.
TESTED=Change in the settings UI was correctly reflected in the same window, in incognito window, and for synced settings also on a synced computer.
BUG=452388
Review URL: https://codereview.chromium.org/1252973002
Cr-Commit-Position: refs/heads/master@{#340475}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are 3 reasons for removing this:
1) It is currently unused and untested
2) It has not been updated to not store the setting for each content type in a
different pref (everything is in one pref). We don't want this because we
don't want values for all content types to be synced. So it wouldn't be
useful in its current form anyway.
3) Its existence makes it harder to do refactoring in content settings at the
moment.
BUG=512683
TBR=markusheintz@chromium.org
Review URL: https://codereview.chromium.org/1252253002
Cr-Commit-Position: refs/heads/master@{#340424}
|
|
|
|
|
|
|
|
| |
This converts calls from the old form to the new form. Some calls that iterated over the results were changed to a range-based for loop with an inline call to SplitString. Some places were changed to use StringPieces when it was safe to do so.
Review URL: https://codereview.chromium.org/1234973004
Cr-Commit-Position: refs/heads/master@{#340209}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the quota database is asked for the least recently used origin for
eviction it should not return any origins that have been granted the
durable storage permission.
Note that there is no easy way for a user to set this permission yet.
That is coming in https://codereview.chromium.org/1164073005/ and
https://codereview.chromium.org/1154573005/
BUG=482814
Review URL: https://codereview.chromium.org/1229933007
Cr-Commit-Position: refs/heads/master@{#339783}
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces it with base::StartsWith and the appropriate case flag. Since the existing version only ever did case-insensitive tests in ASCII, there should be no behavior change.
BUG=506255
TBR=jam
Review URL: https://codereview.chromium.org/1242023005
Cr-Commit-Position: refs/heads/master@{#339175}
|
|
|
|
|
|
|
|
|
|
|
| |
Split off from https://codereview.chromium.org/1164073005/ to keep the
permission-requesting and quota logic changes clearer.
BUG=482814
Review URL: https://codereview.chromium.org/1217893006
Cr-Commit-Position: refs/heads/master@{#337331}
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL splits the factory in a separate file and moves the service in
the component.
The class is also moved to the content_settings namespace.
BUG=503973
TBR=jochen
Review URL: https://codereview.chromium.org/1214763002
Cr-Commit-Position: refs/heads/master@{#336745}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL prepares CookieSettings for componentization, so that it can be
shared with the iOS platform.
The detailed changes are:
- the extension scheme is injected through the constructor,
- the kBlockThirdPartyCookies preference is componentized,
- threads checks with ThreadChecker instead of BrowserThread,
- metrics are moved to the factory.
Note that the CookieSettings factory is not going to be componentized.
Follow up CLs will split the factory in a separate file and move
CookieSettings to //components/content_settings/core/browser.
BUG=503973
TBR=jochen
Review URL: https://codereview.chromium.org/1219433002
Cr-Commit-Position: refs/heads/master@{#336383}
|
|
|
|
|
|
|
|
|
|
| |
The are currently not persisted anywhere.
BUG=464234
Review URL: https://codereview.chromium.org/1187113002
Cr-Commit-Position: refs/heads/master@{#336312}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename IsWhitespace to IsUnicodeWhitespace (to contrast it to the already-existing IsAsciiWhitespace).
De-inline HexDigitToInt. This is only used in a few places and I don't think it's necessary to inline.
Remove some redundant base:: qualifications in base.
TBR=sky
Review URL: https://codereview.chromium.org/1200053004
Cr-Commit-Position: refs/heads/master@{#335827}
|
|
|
|
|
|
|
|
| |
BUG=416479
Review URL: https://codereview.chromium.org/1178683009
Cr-Commit-Position: refs/heads/master@{#334703}
|
|
|
|
|
|
|
|
|
| |
NOPRESUBMIT=true
(no presubmit due to removing base:: from a ScopedAllowIO)
Review URL: https://codereview.chromium.org/1172183002
Cr-Commit-Position: refs/heads/master@{#334108}
|
|
|
|
|
|
|
|
| |
BUG=479227
Review URL: https://codereview.chromium.org/1166603002
Cr-Commit-Position: refs/heads/master@{#333219}
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is using RenderFrameHost instead of WebContents so it's possible
to know to associate a request and a frame. Each request will then be
defined by its process id, its frame id and its request id, making it
entirely unique.
BUG=491923
Review URL: https://codereview.chromium.org/1158813002
Cr-Commit-Position: refs/heads/master@{#332635}
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is everything but the chrome directory
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
TBR=zelidrag@chromium.org (chromeos)
TBR=keybuk@chromium.org (device/bluetooth)
Review URL: https://codereview.chromium.org/1162943002
Cr-Commit-Position: refs/heads/master@{#332626}
|
|
|
|
|
|
|
|
| |
BUG=491031
Review URL: https://codereview.chromium.org/1154703004
Cr-Commit-Position: refs/heads/master@{#332152}
|
|
|
|
|
|
|
|
|
|
| |
This code has been unused for 8+months.
BUG=492024
Review URL: https://codereview.chromium.org/1156983002
Cr-Commit-Position: refs/heads/master@{#332150}
|
|
|
|
|
|
|
|
| |
BUG=427616
Review URL: https://codereview.chromium.org/1101713004
Cr-Commit-Position: refs/heads/master@{#332002}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are many callers, so all could not be updated at once. The old version is renamed to JSONReader::DeprecatedRead, and a new version of JSONReader::Read that returns scoped_ptr takes its place.
Much of this patch was generated with sed. Some callsites of the form
scoped_ptr<Value> value(Read());
have been updated to
scoped_ptr<Value> value = Read();
but most Read() calls are simply converted to DeprecatedRead. Actually updating them is a TODO.
BUG=none
Review URL: https://codereview.chromium.org/1136643005
Cr-Commit-Position: refs/heads/master@{#331120}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SchemeIsSecure().
We recently introduced SchemeIsCryptographic() and IsOriginSecure(),
which are meant to replace SchemeIsSecure().
IsOriginSecure() roughly means "do we trust this content not to be
tampered with before it reaches the user?" [1] This is a higher-level
definition that corresponds to the new "privileged contexts" spec. [2]
SchemeIsCryptographic() [3] is close to the old definition of
SchemeIsSecure(), and literally just checks if the scheme is a
cryptographic scheme (HTTPS or WSS as of right now). The difference is
that SchemeIsCryptographic() will not consider filesystem URLs secure.
[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/origin_util.h&sq=package:chromium&type=cs&l=19&rcl=143099866
[2] https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and https://w3c.github.io/webappsec/specs/powerfulfeatures/
[3] https://code.google.com/p/chromium/codesearch#chromium/src/url/gurl.h&sq=package:chromium&type=cs&l=250&rcl=1430998666
BUG=362214
Review URL: https://codereview.chromium.org/1128363006
Cr-Commit-Position: refs/heads/master@{#329269}
|
|
|
|
|
|
|
|
|
| |
R=tommycli@chromium.org,bauerb@chromium.org
BUG=478918
Review URL: https://codereview.chromium.org/1112723002
Cr-Commit-Position: refs/heads/master@{#327546}
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have added PrefRegistry registration functions that do not need to
accept a flags argument, passing PrefRegistrySyncable::UNSYNCABLE_PREF is
redundant and we can remove it altogether.
BUG=476800
Review URL: https://codereview.chromium.org/1092683004
Cr-Commit-Position: refs/heads/master@{#327439}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have added PrefRegistry registration functions that do not need to
accept a flags argument, passing PrefRegistrySyncable::UNSYNCABLE_PREF is
redundant and we can remove it altogether.
Ran the following command:
for x in $(git ls-files | grep -E "\.(cc|h|mm)$") ; do perl -0777 -i -pe 's/,[ \n]*(user_prefs::)+PrefRegistrySyncable::UNSYNCABLE_PREF//igs' $x ; done && git cl format
There are still some occurences that need to be manually fixed.
BUG=476800
Review URL: https://codereview.chromium.org/1102733002
Cr-Commit-Position: refs/heads/master@{#326993}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to use
MEDIASTREAM content setting for media default ( ASK / BLOCK )
CAMERA / MIC content settings for media exceptions ( ALLOW / ASK / BLOCK )
When we stopped using MEDIASTREAM and replaced it with CAMERA / MIC for defaults as well, we didn't ensure that the ALLOW value is still unsupported as default.
This CL fixes that. Although during the short period when the default settings supported ALLOW values we had no UI to set it, we include a migration code just to be on the safe side.
BUG=464382
Review URL: https://codereview.chromium.org/1092743005
Cr-Commit-Position: refs/heads/master@{#326486}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on the results of a FieldTrial (also flags).
Still respect the user's choice when they've explicitly chosen an
alternative (e.g. they chose to BLOCK all plugins).
R=tommycli@chromium.org,bauerb@chromium.org,jochen@chromium.org
TBR=markusheintz@chromium.org
BUG=476742
Review URL: https://codereview.chromium.org/1084123002
Cr-Commit-Position: refs/heads/master@{#325846}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In DefaultProvider, we're currently locking the entire operation of changing a default content setting:
1. Changing the setting in the cache
2. Changing the individual preference
3. Possibly changing the dictionary preference
In fact, only the cache access is multi-threaded and should be locked. Locking the preference access can lead to a situation where the same thread re-acquires the non-reentrant lock, such as when a preference is written by a non-incognito provider, what causes a preference read from the incognito provider, on the same (UI) thread.
BUG=476826
Review URL: https://codereview.chromium.org/1081103003
Cr-Commit-Position: refs/heads/master@{#325028}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means that if a resource identifier rule (e.g. plugin allowed on a site) is delete in an old instance of Chrome, the deletion will not propagate to a new version.
This change also affects ProfileResetter, which calls this function to delete all content settings rules; it did not delete rules with resource identifier before.
Since the OriginIdentifierValueMap now only contains one content type per instance, we can delete all rules (regardless of resource identifier) by simply calling clear(), which greatly improves the deletion speed as well.
BUG=475951
Review URL: https://codereview.chromium.org/1079133003
Cr-Commit-Position: refs/heads/master@{#325022}
|
|
|
|
|
|
|
|
|
|
| |
The DefaultProvider used an array to remember which settings are syncable. We should use the function IsContentSettingsSyncable(), so that DefaultProvider and PrefProvider refer to the same source.
BUG=452388
Review URL: https://codereview.chromium.org/1063253006
Cr-Commit-Position: refs/heads/master@{#324831}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
//components/contents_settings for IPC
In preparation for moving chrome/renderer/content_settings_observer.cc into //components/contents_settings, this CL moves all IPC messages used in that file to a separate IPC declaration header in //components/contents_settings.
The main parts of the change:
* separating messages from chrome/common/render_messages.h to newly created components/content_settings/content/common/content_settings_messages.h
* adding the support files in components/content_settings/content/common/
* extending the filter in chrome/browser/renderer_host/chrome_render_message_filter.cc to catch content settings IPC
* and, of course, removing #include "chrome/common/render_messages.h" from content_settings_observer.cc
The rest is mostly adding #includes and mechanical changes.
BUG=384874,387075
Review URL: https://codereview.chromium.org/798923003
Cr-Commit-Position: refs/heads/master@{#324644}
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is follow up of issue 399592 for replacing NO_RESOURCE_IDENTIFER with
ResourceIdentifier, With these changes their will be no std::String() in content_settings.
so usage is more consistent.
BUG=475862
Review URL: https://codereview.chromium.org/1076153002
Cr-Commit-Position: refs/heads/master@{#324619}
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard (non-incognito) value map of an incognito ContentSettingsPref instance was not initialized. It should be initialized with the contents of the preference.
The effect was that the incognito session only acknowledged settings that were set after it started.
BUG=474462
Review URL: https://codereview.chromium.org/1077693002
Cr-Commit-Position: refs/heads/master@{#324615}
|
|
|
|
|
|
|
|
| |
Addressing comments from CL 1004733003.
Review URL: https://codereview.chromium.org/1038203003
Cr-Commit-Position: refs/heads/master@{#324403}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patterns are internally sorted from the lowest precedence to highest (i.e.
from the less specific pattern to the most specific, though the rules are more
complicated than that), and they were shown to the user in this order too,
which was confusing and making them think it's not sorted at all. Showing the
highest precedence patterns first should be more intuitive and also sort the
equivalent patterns more-or-less alphabetically.
BUG=450580
Review URL: https://codereview.chromium.org/1047153002
Cr-Commit-Position: refs/heads/master@{#324392}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NO_RESOURCE_IDENTIFIER.
current NO_RESOURCE_IDENTIFIER usage is aganinst style guidelines.
Made a class in content_settings.h and using function to get std::string()
To get rid of NO_RESOURCE_IDENTIFIER.
Now no need to add content_settings_provider.h in places like
desktop_notification_profile_util.cc and other places.
BUG=399592
Review URL: https://codereview.chromium.org/1034143002
Cr-Commit-Position: refs/heads/master@{#324362}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all content types into separate dictionary holding one content type each.
Old dictionary entry example:
"www.google.com,*": {"cookies": <value>, "plugins": <value>, last_used: {"cookies": <timestamp>, "plugins": <timestamp>}, "per_plugin": {<resource_id>: <value>}}
Split into separate dictionaries:
cookies:
"www.google.com,*": {"setting": <value>, "last_used": <timestamp>}
plugins:
"www.google.com,*": {"setting": <value>, "last_used": <timestamp>, "per_resource": {<resource_id>: <value>}}
For migration between versions of Chrome, we use a similar logic as when we migrated the default preferences in https://codereview.chromium.org/1004733003/ .
1. On the first run, migrate all settings (PrefProvider::MigrateAllExceptions()).
2. Whenever the old dictionary preference changes, propagate the syncable entries into the new preferences (PrefProvider::OnOldContentSettingsPatternPairsChanged()).
3. Whenever one of the new preferences changes, and it is syncable, we write it back to the old dictionary preference as well (ContentSettingsPref::OnPrefChanged()).
Note that PrefProvider manages its old dictionary preference the same way as ContentSettingsPref does a new preference, and ContentSettingsPref needs access to the old preference as well, which leads to some duplication in the code (UpdateOldPref() is just a modified version of UpdatePref(); both use some of the same constructs). We use the convention of referring to attributes and methods managing the old dictionary preference as "old" in the name.
BUG=452388
Review URL: https://codereview.chromium.org/1005303003
Cr-Commit-Position: refs/heads/master@{#323585}
|