Index: chrome/browser/sync/profile_sync_service_harness.cc |
diff --git a/chrome/browser/sync/profile_sync_service_harness.cc b/chrome/browser/sync/profile_sync_service_harness.cc |
index b2b251e1f8792dfe19f6fdff5d54dd649ae5a9cd..9096f7f8c3a63998cd48ea08398dbf0158c450e5 100644 |
--- a/chrome/browser/sync/profile_sync_service_harness.cc |
+++ b/chrome/browser/sync/profile_sync_service_harness.cc |
@@ -653,7 +653,14 @@ bool ProfileSyncServiceHarness::AwaitMigration( |
<< " after migration finish is not WAITING_FOR_NOTHING"; |
return false; |
} |
- if (!AwaitFullSyncCompletion( |
+ // We must use AwaitDataSyncCompletion rather than the more common |
+ // AwaitFullSyncCompletion. As long as crbug.com/97780 is open, we will |
+ // rely on self-notifiations to ensure that timestamps are udpated, which |
akalin
2012/01/20 23:09:29
self-notifiations -> self-notifications
|
+ // allows AwaitFullSyncCompletion to return. However, in some migration |
+ // tests these notifications are completely disabled, so the timestamps do |
+ // not get updated. This is why we must use the less strict condition, |
+ // AwaitDataSyncCompletion. |
+ if (!AwaitDataSyncCompletion( |
"Config sync cycle after migration cycle")) { |
return false; |
} |
@@ -890,7 +897,7 @@ bool ProfileSyncServiceHarness::EnableSyncForDatatype( |
synced_datatypes.Put(syncable::ModelTypeFromInt(datatype)); |
service()->OnUserChoseDatatypes(false, synced_datatypes); |
- if (AwaitFullSyncCompletion("Datatype configuration.")) { |
+ if (AwaitDataSyncCompletion("Datatype configuration.")) { |
DVLOG(1) << "EnableSyncForDatatype(): Enabled sync for datatype " |
<< syncable::ModelTypeToString(datatype) |
<< " on " << profile_debug_name_ << "."; |