[Sync] Sync the chrome://history page

chrome/browser/sync/sessions/sessions_util.cc

Index: chrome/browser/sync/sessions/sessions_util.cc
diff --git a/chrome/browser/sync/sessions/sessions_util.cc b/chrome/browser/sync/sessions/sessions_util.cc
index e5a9384d9640a2b9c2a32ca882e8fe1684ff2e61..b304d17479bb9cf81ce5eb416fc48875a6a8fe9e 100644
--- a/chrome/browser/sync/sessions/sessions_util.cc
+++ b/chrome/browser/sync/sessions/sessions_util.cc
@@ -39,6 +39,10 @@ bool ShouldSyncTab(const SyncedTabDelegate& tab) {
         !virtual_url.SchemeIs(chrome::kChromeNativeScheme) &&
         !virtual_url.SchemeIsFile()) {
       found_valid_url = true;
+    } else if (virtual_url == GURL(chrome::kChromeUIHistoryURL)) {
+      // The history page is treated specially as we want it to trigger syncable

[stanisc, 2015/04/14 22:42:40]

Wouldn't there be a race condition between the page loading and Sync backend
initializing? How does this guarantee DeviceInfo to be initialized by the time
the page loads? Would history page refresh on its own once DeviceInfo becomes
available?

[Nicolas Zea, 2015/04/16 17:30:30]

Yes, but that's fine. Once we do model association we'll capture whatever the
contents of the page is. And yes, the history page will refresh on its own once
the synced tab state is available (it doesn't actually depend on device info).

+      // events for UI purposes.
+      found_valid_url = true;

[stanisc, 2015/04/14 22:42:40]

Perhaps break the loop (here and above) once the valid url is found.

[Nicolas Zea, 2015/04/16 17:30:29]

We actually deliberately keep looping to ensure that all the entries in the
navigation stack are valid (and return false early if not, in line 35).

     }
   }
   return found_valid_url;