Fix the sync sign in dialog issues for app notifications:

chrome/browser/sync/profile_sync_service.cc

 // Copyright (c) 2011 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.
 
 #include "chrome/browser/sync/profile_sync_service.h"
 
 #include <algorithm>
 #include <cstddef>
 #include <map>
 #include <set>
@@ skipping 1458 matching lines @@
       break;
     }
     case chrome::NOTIFICATION_TOKEN_AVAILABLE: {
       const TokenService::TokenAvailableDetails& token_details =
           *(content::Details<const TokenService::TokenAvailableDetails>(
               details).ptr());
       if (IsTokenServiceRelevant(token_details.service()) &&
           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();
       }
       break;
     }
     case chrome::NOTIFICATION_TOKEN_LOADING_FINISHED: {
       // This notification gets fired when TokenService loads the tokens
       // from storage. Here we only check if the chromiumsync token is
       // available (versus both chromiumsync and oauth login tokens) to
@@ skipping 104 matching lines @@
              << "Unrecoverable error.";
   } else {
     DVLOG(0) << "ConfigureDataTypeManager not invoked because backend is not "
              << "initialized";
   }
 }
 
 const FailedDatatypesHandler& ProfileSyncService::failed_datatypes_handler() {
   return failed_datatypes_handler_;
 }