Fix the sync sign in dialog issues for app notifications:

chrome/browser/sync/profile_sync_service.cc

Index: chrome/browser/sync/profile_sync_service.cc
===================================================================
--- chrome/browser/sync/profile_sync_service.cc	(revision 112743)
+++ chrome/browser/sync/profile_sync_service.cc	(working copy)
@@ -1476,6 +1476,20 @@
           AreCredentialsAvailable(true)) {
         if (backend_initialized_) {
           backend_->UpdateCredentials(GetCredentials());
+          const GoogleServiceAuthError& last_error = GetAuthError();
+          if (GoogleServiceAuthError::NONE == last_error.state()) {
+            // SyncBackendHost::UpdateCredentials call does not call back
+            // OnAuthError in cases when the underlying syncer state does not
+            // change. Due to that if the login dialog is showing up when the
+            // credentials have not expired as such (this happens when login
+            // dialog is shown by app notifications setup code) the login dialog
+            // will show the spinner forever. Hence, we call OnAuthError
+            // explicitly here to avoid the infinite spinner in that case.
+            // Note that SyncBackendHost::UpdateCredentials may actually end up
+            // failing, but in that case an error will be shown to the user in
+            // bookmarks bar and preferences.
+            OnAuthError();

[tim (not reviewing), 2011/12/06 23:39:31]

Why did we do this this way?  From my email, I suggested "...making it so you
can refresh credentials in the SyncManager, and be notified asynchronously of
that finishing right up to the top of the stack that originated the
UpdateCredentials call in the first place (in ProfileSyncService). "

This seems like more of a hack, so I'm curious what obstacles there were with
the other route (changing it in sync manager).

[Munjal (Google), 2011/12/07 00:05:14]

The main reason is that this seemed the safest (lowest risk) thing to do in
various discussions with Lingesh and Drew. In fact, Lingesh and Drew
independently mentioned the same approach.

FWIW, our analyses of the code concluded that actually PSS does not need to wait
for a callback from SBH::UpdateCredentials since that only ends up calling
gettime, which is not an authenticated call anyway. Lingesh and Kevin and I
concluded that.

So, if we are right, the right change to do would be to fix that PSS <-> SBH
communication when a user is authenticated.

+          }
         }
         if (!sync_prefs_.IsStartSuppressed())
           StartUp();