Register a pref to control migration status

components/content_settings/core/browser/host_content_settings_map.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Maps hostnames to custom content settings.  Written on the UI thread and read
 // on any thread.  One instance per profile.
 
 #ifndef COMPONENTS_CONTENT_SETTINGS_CORE_BROWSER_HOST_CONTENT_SETTINGS_MAP_H_
 #define COMPONENTS_CONTENT_SETTINGS_CORE_BROWSER_HOST_CONTENT_SETTINGS_MAP_H_
 
@@ skipping 21 matching lines @@
 namespace base {
 class Clock;
 class Value;
 }
 
 namespace content_settings {
 class ObservableProvider;
 class ProviderInterface;
 class PrefProvider;
 class TestUtils;
+
+// Enum describing status of migration process. This is to ensure that migration

[raymes, 2016/07/19 01:48:15]

nit: Enum describing the status of domain to origin migration of content
settings. Migration will be done twice: once upon construction of the
HostContentSettingsMap (before syncing any content settings) and once after sync
has finished. We always migrate before sync to ensure that settings will get
migrated even if a user doesn't have sync enabled. We migrate after sync to
ensure that any sync'd settings will be migrated. Once these events have
occurred, we won't perform migration again.

[lshang, 2016/07/20 06:16:20]

Done.

+// only done once.
+enum ContentSettingMigrationStatus {

[raymes, 2016/07/19 01:48:15]

We should be more specific about what migration this is for (there are many
things to migrate :). We could call it DomainToOriginMigrationStatus.

[lshang, 2016/07/20 06:16:21]

Done.

+  // Haven't been migrated at all.
+  NOT_MIGRATED,
+  // Have done migration in the constructor of HostContentSettingsMap.
+  DONE_IN_HCSM,

[raymes, 2016/07/19 01:48:15]

I would just differentiate MIGRATED_BEFORE_SYNC and MIGRATED_AFTER_SYNC

[lshang, 2016/07/19 07:45:56]

I think we need to have three states here:

- haven't migrated, so that we can run it in HCSM constructor

- MIGRATED_BEFORE_SYNC, which means we have run it in HCSM, so we will not do it
again on the next chrome start, but can run it in sync

- MIGRATED_AFTER_SYNC, which means we have run it in sync, so the migration code
won't get run again at anywhere

if we omit the first state, and user didn't enable sync, then we will never know
if we should run the migration in HCSM on browser start.

Does my point seem reasonable? I'm happy to discuss more in person:-)

[lshang, 2016/07/20 06:16:20]

Done.

+  // Have done migration both in HostContentSettingsMap construction and sync
+  // process(this is a clean up after sync). Migration is all finished at this
+  // stage.
+  DONE_IN_HCSM_AND_SYNC,
+};

[raymes, 2016/07/19 01:48:15]

We could move this into the .cc file

[lshang, 2016/07/20 06:16:21]

Done.

 }
 
 namespace user_prefs {
 class PrefRegistrySyncable;
 }
 
 class HostContentSettingsMap : public content_settings::Observer,
                                public RefcountedKeyedService {
  public:
   enum ProviderType {
@@ skipping 345 matching lines @@
   base::ThreadChecker thread_checker_;
 
   base::ObserverList<content_settings::Observer> observers_;
 
   base::WeakPtrFactory<HostContentSettingsMap> weak_ptr_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(HostContentSettingsMap);
 };
 
 #endif  // COMPONENTS_CONTENT_SETTINGS_CORE_BROWSER_HOST_CONTENT_SETTINGS_MAP_H_