Disable checkboxes in the advanced sync settings overlay whose type is force-enabled.

chrome/browser/sync/profile_sync_service.cc

Index: chrome/browser/sync/profile_sync_service.cc
diff --git a/chrome/browser/sync/profile_sync_service.cc b/chrome/browser/sync/profile_sync_service.cc
index d46a0e76b7e51b138b82b8af42ef9d996ab8c120..1a8fbedc719d2465cf6d428bd337ffa09f12295d 100644
--- a/chrome/browser/sync/profile_sync_service.cc
+++ b/chrome/browser/sync/profile_sync_service.cc
@@ -1892,7 +1892,7 @@ syncer::ModelTypeSet ProfileSyncService::GetPreferredDataTypes() const {
   const syncer::ModelTypeSet registered_types = GetRegisteredDataTypes();
   const syncer::ModelTypeSet preferred_types =
       sync_prefs_.GetPreferredDataTypes(registered_types);
-  return preferred_types;
+  return Union(preferred_types, GetDataTypesFromPreferenceProviders());

[Marc Treib, 2014/08/21 09:12:24]

I think this should already have been in the previous CL.

[Nicolas Zea, 2014/08/21 23:33:53]

Yes. This might actually be something we should merge into m38, if the logic is
being used there. Without this certain logic breaks (e.g. requesting sync
startup early, a couple other cases). If there are no forced types in m38 though
its stay in 39.

That said, it occurs to me that the GetDataTypesFromPreferenceProviders should
return the intersection with RegisteredTypes. Otherwise types that aren't
supported in that version are included.

[Marc Treib, 2014/08/22 08:36:38]

Intersection with RegisteredTypes done.
I don't think a merge will be necessary: Supervised users do use forced types,
but (for now) those are known at profile creation time and never change. They
also cannot (re)configure sync at all atm. So I think we'll be good without a
merge.

 }
 
 syncer::ModelTypeSet
@@ -1901,7 +1901,6 @@ ProfileSyncService::GetPreferredDirectoryDataTypes() const {
       GetRegisteredDirectoryDataTypes();
   const syncer::ModelTypeSet preferred_types =
       sync_prefs_.GetPreferredDataTypes(registered_directory_types);
-
   return Union(preferred_types, GetDataTypesFromPreferenceProviders());
 }
 
@@ -1910,6 +1909,14 @@ ProfileSyncService::GetPreferredNonBlockingDataTypes() const {
   return sync_prefs_.GetPreferredDataTypes(GetRegisteredNonBlockingDataTypes());
 }
 
+syncer::ModelTypeSet
+ProfileSyncService::GetNonUserChoicePreferredDataTypes() const {
+  // TODO(treib,zea): When SyncPrefs also implements SyncTypePreferenceProvider,
+  // we'll need another way to distinguish user-choosable types from
+  // programmatically-enabled types.
+  return GetDataTypesFromPreferenceProviders();

[Nicolas Zea, 2014/08/21 23:33:53]

For now we could look at the difference between the two. I.e.
ModelTypeSet::Difference(sync_prefs_.GetPreferredDataTypes(),
GetPreferredDataTypes).

[Marc Treib, 2014/08/22 08:36:38]

That would give us the types that *can* be chosen by the user, i.e. the
complementary set, yes? Do you see an advantage of that over what I've been
doing?

[Nicolas Zea, 2014/08/22 17:26:47]

Note that I'm assuming GetPreferredDataTypes already includes the
GetDataTypesFromPreferenceProviders. So the difference would be those that are
in the forced set, but not in the sync_prefs_ set, which I believe is what we
want.

That said, now that I think about it there's not really any need to do a set
difference here, since the SyncPrefs aren't a SyncTypePreferenceProvider (yet).
So this is fine as is.

+}
+
 syncer::ModelTypeSet ProfileSyncService::GetRegisteredDataTypes() const {
   return Union(GetRegisteredDirectoryDataTypes(),
                GetRegisteredNonBlockingDataTypes());