New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 128592 link

Starred by 15 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Jun 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 0
Type: Bug-Regression

Blocking:
issue 128742

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

First time sync cannot be initialized

Project Member Reported by rohi...@chromium.org, May 17 2012

Issue description

Version: 20.0.1132.11 
OS: ChromeOS 2268.16.0

What steps will reproduce the problem?
1. Connect ChromeOS device to any wifi network.
2. Login using any gmail account.
3. Check for the sync status from chrome://sync page.

What is the expected output?
3.1 Sync is enabled. Bookmarks and apps are downloaded on the machine.

What do you see instead?
3.2 Sync is not enabled.

Note:
- I am seeing this problem on multiple ChromeOS devices today.
- Logs and screenshot : http://cros-hwqual-5.mtv.corp.google.com/bugs/128327/ .
 
Clicking 'Set up Sync' button from settings page, I see an infinite spin dialog.
Labels: -Type-Bug Type-Regression
I see the first time sync set up is incomplete. Screenshot: http://cros-hwqual-5.mtv.corp.google.com/bugs/screenshots/screenshot-20120517-121852.png

Sync is enabled after logout and login back.
Owner: kochi@chromium.org
I know there are some issues with fetching sync tokens due to cros interactions with dos-server, which may be related.

Assigning to Kochi to investigate the "infinite spin" - i'm guessing the problem is that we don't have a token for sync, so the backend never starts up. We should probably detect this in the PrepareConfigDialog() code and display an error instead of a spinner.

Comment 5 by ddrew@chromium.org, May 17 2012

Status: Assigned
Is this only affecting first-time setup? If not, is there any possibility of existing users losing any sync data (e.g.: if they add bookmarks which are then lost the next time they do sync)?

Comment 6 by krisr@chromium.org, May 17 2012

- This is when you create a new user, and after multiple reboots it cannot be fixed.
- We do not see this after auto-update.

Comment 7 by kochi@chromium.org, May 18 2012

> comment 4

I filed  issue 128692 .
This issue is currently considered caused by DoS-server returning error.

> commment 5

This may happen at any time that the client request token to the server and
the server returns error, i.e. not only restricted to the first-time setup
but also upon GAIA login after once the account is setup.

If the server-side issue is addressed, the user should recover the sync state
on sign out and sign in again.  The re-login should refresh the token for sync. 
Sync system should merge the local changes with data saved in the cloud, and no
user data loss is expected.  If any data loss is observed, please file another bug.

As I understand this is serious and worth Pri-0, but from the client side we don't
have much to do except showing error to user, currently.

I'll close this once the server side issue is resolved.

Comment 8 by ddrew@chromium.org, May 18 2012

Is   issue 128692  the bug tracking the server-side change? If so, that needs to be escalated to a P0 as it appears to be blocking our launch. If it's not, what is the correct bug tracking that problem?

Comment 9 by ddrew@chromium.org, May 18 2012

Labels: Noteworthy
 Issue 128792  has been merged into this issue.
Summary: Tokens not refreshed on ChromeOS login due to DoS-server error; sync is not enabled
Based on comment 7, adjusting title to reflect better the root cause. This should affect all services behind signin?
It seems that issue 127147 is tracking the root-cause and is marked as P0.

kochi@, between  issue 128692  and issue 127147, is there anything outstanding here? Please feel free to adjust priority accordingly, if the latter also unblocks sync.

Comment 13 by kochi@chromium.org, May 21 2012

Mergedinto: 127147
Status: Duplicate
127147 seems the one which caused DoS service to block sync.

Now it seems the DoS service blocking rule issue is resolved, and I cannot repro this
locally with GoogleGuest network.

For  issue 128692 , I think the priority is not as high as this.

Merging to 127147.
Sync still doesn't work on M20 build Chrome 20.0.1132.13 / ChromeOS 2268.21.0 .

Comment 15 by sumit@chromium.org, May 21 2012

Nothing has changed to R20 wrt URLs, so if sync does not work, that's probably not related to 127147.
Labels: -ReleaseBlock-Dev ReleaseBlock-Beta
Mergedinto:
Status: Assigned
As Sumit said, de-duping this issue from Issue 127147.  Marking this as a beta blocker since this is only for new users.
If you are still seeing a repro: how large is the account that was tested with. First time sync on a first sign in with a large account could result in a palpable lag. 

Comment 18 by ddrew@chromium.org, May 21 2012

Owner: annapop@chromium.org
Summary: First time sync cannot be initialized
Looking at the logs now with Zel, and this is not a GAIA auth issue anymore (which btw affected only M21/TOT). Sync client is not able to parse the results from the server:


[1620:3766:82584437:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): 401 Content-Length (bogus on error): 147 Server Status: 4
[1620:3766:82584772:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1620:3766:84586148:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
[1620:3766:84586282:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1620:3766:87587314:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
[1620:3766:87587420:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
...

[1620:3766:92588708:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
[1620:3766:92588860:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1620:3766:104589979:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
[1620:3766:104758158:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1620:3766:122759842:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
[1620:3766:122759972:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1620:3766:149761276:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
[1620:3766:149761415:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1620:3766:216762653:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
[1620:3766:216762828:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1620:3766:317764158:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
...

[1620:3766:469765426:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4
...

[1620:3766:849766913:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 4

I am using very lightweight accounts to login on my ChromeOS test machines.

- Profile picture loads on picture selection screen after a first login.
- Bookmarks or any other settings don't load after login.
- I saw that after any browser crash, sometimes sync starts working.
- Summary says 'First time sync setup incomplete'.
- I will attach logs from my machine.
I have copied system logs including profile data and Sync data at http://cros-hwqual-5.mtv.corp.google.com/bugs/128592/
Owner: raz@chromium.org
Thanks, Danielle and Rohit! Transferring some more context from offline discussion: this is on build 2268.21.0 and after disabling the proxy, sync was enabled though with some lag.

Looking at the logs above, the first line is an auth error and this is consistent with the behavior kochi@ observed in issue 128327, as well as reported in  issue 128417 .

Before we merge some of the threads and narrow down on the culprit, Raz, is there anything in the log output after the auth error that is suspect?

Comment 22 by zea@chromium.org, May 22 2012

Owner: zea@chromium.org
Took a look at our server logs, and there's definitely something weird going on with the client. On 5/17, at around 12:17pm, a Cros 20.0.1121.11 device starts doing a NEW_CLIENT GetUpdates request to the server pretty much continuously for the next two minutes, about 20 times a second, each time with a new client id.

The server's response code is 200 for each of these, and includes the nigori node for that client. Everything appears fine from the server point of view (same store birthday is sent each time). For some reason though, none of the clients (and they all have the same IP) attempt any further communication.

These attempts then stop at 12:18:29. There's no activity until 6:02pm later that evening, at which point a new client (with a different IP from all the previous clients, so I'm assuming a different device) comes online and proceeds to successfully set up sync it appears (Client Id AIjDAhoeIkgnFMdYjyNsiQ==). There is no further activity after that day.

Right now, the best I can come up with is that there's something preventing us from successfully writing into the directory. As a result, it's possible we trigger some sort of error, which on ChromeOS is resulting in recreating the directory, hence the new client id.

Has this been repro'd with any other device? I wonder if there's some sort of memory/hard disk issue on this particular device causing issues. I'll see if I can get something out of the logs that can corroborate that, although Kochi or something else from ChromeOS might be more familiar with hardware issues.

Comment 23 by zea@chromium.org, May 22 2012

Actually, those logs appear to be from around 6:20pm, e.g. from the client that succeeded in connecting. So it's possible there's two issues here.

Also, disregard my comment about assuming it was a new device, it could have just been a different network (which perhaps matches the comments about it working once out from behind the proxy). Still, the fact that while the client was behind the proxy it connected so quickly is definitely concerning. That's likely a separate issue though.

So far I'm only aware of chromeostest002 that's hit this issue. Anna mentioned ddrew's corp account has as well? Those who have hit this, it would be helpful if you posted the account as well as the approximate time you attempted to sign in.
This has been only observed on ChromeOS, accounts exhibiting the behavior are able to sign in on desktop during the same time frame.

Comment 25 by ddrew@chromium.org, May 22 2012

ddrew corp account today around 2pm seeing this problem, as well as on
Friday - couldn't say specific times, but noon-ish I'd say.

Comment 26 by zea@chromium.org, May 22 2012

Also, so that I'm completely clear, since I'm still playing a bit of catch up: what exactly are the symptoms of "this problem"?

From what I can gather, new users are unable to sign in to a chromeos device while they're behind a proxy. Once they get out from behind the proxy it succeeds in signing in? Are existing chromeos users who are behind a proxy unaffected and still able to sync?
@zea, login to ChromeOS works fine. This is only a first time sync problem on ChromeOS.

Comment 28 by ddrew@chromium.org, May 22 2012

Symptoms I saw were:
- Image a machine and enterprise-enrolled it.
- Login to machine with google.com address using GoogleGuest. Tried to
sync, but got the forever spinner. After rebooting a few times or just
waiting quite a long time (about 45+ minutes to longer) it was finally able
to start syncing.
- Also tried logging in to same machine on GoogleGuest with my
gmail.comaccount and was also unable to sync.

Comment 29 by zea@chromium.org, May 22 2012

Have you tried on older versions? (m18/m19) Did it repro there as well?

From looking at the server logs, I'm not seeing anything that stands out on ddrew's corp account. From the time the server receives the first GetUpdates for a new client, to the time that client starts committing open tabs data, only 30-45 seconds have elapsed. So it appears that something is preventing the client from reaching the server in the first place for those 30 minutes or so you mentioned (for example a 401 error due to GAIA or DosServer).

I tried setting up a new user with a test account of mine on an m18 chromeos device (while on GoogleGuest), and sign in went smoothly. I'll see if the same happens on a newer build.

Comment 30 by zea@chromium.org, May 22 2012

Okay, just repro'd on an m20 build with that same account, investigating further...

Comment 31 Deleted

Comment 32 by ddrew@chromium.org, May 22 2012

I was not able to repro this on R19 build.

Comment 33 by zea@chromium.org, May 22 2012

Cc: rogerta@chromium.org atwilson@chromium.org
Okay, I'm seeing what might be OAUTH issues here actually. When I went into net-internals, I never actually saw any connections to clients4.google.com. The only periodic connections where to talk.google.com. Turning on the verbose logging and inspecting that, I see the following messages:

[5736:5736:90240780:VERBOSE1:login_utils.cc(1126)] Setting first login prefs
[5736:5736:90741780:VERBOSE1:login_utils.cc(1277)] Got OAuth request token!
[5736:5772:91010146:VERBOSE1:http_auth_controller.cc(256)] The server https://clients4.google.com/ requested auth 
  Has header WWW-Authenticate: GoogleLogin realm="https://www.google.com/accounts/ClientLogin", service="chromiumsync"
[5736:5772:91010291:VERBOSE1:http_auth.cc(44)] Unable to create AuthHandler. Status: net::ERR_UNSUPPORTED_AUTH_SCHEME Challenge: GoogleLogin realm="https://www.google.com/accounts/ClientLogin", service="chromiumsync"
[5736:5852:91011337:WARNING:syncer_proto_util.cc(172)] Error posting from syncer: Response Code (bogus on error): 401 Content-Length (bogus on error): 147 Server Status: 4
[5736:5852:91011574:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates

There aren't any further  messages printed by http_auth (could it be dropping requests on the floor? or giving up since it didn't have the oauth token at the time?), but there are more oauth related messages that happen after:

[5736:5736:91028764:VERBOSE1:gaia_oauth_fetcher.cc(611)] OAuth1 access token fetched.
[5736:5736:91028915:VERBOSE1:login_utils.cc(1289)] Got OAuth v1 token!
[5736:5736:91409530:VERBOSE1:gaia_oauth_fetcher.cc(391)] Starting OAuthWrapBridge for: https://www.googleapis.com/auth/chromeosdevicemanagement
[5736:5736:91708370:VERBOSE1:login_utils.cc(465)] Got OAuth access token for https://www.googleapis.com/auth/chromeosdevicemanagement
[5736:5736:92510597:VERBOSE1:token_service.cc(258)] Got an authorization token for gaia
[5736:5736:92553239:VERBOSE1:token_service.cc(258)] Got an authorization token for chromiumsync
[5736:5736:92553643:VERBOSE1:token_service.cc(258)] Got an authorization token for lso
[5736:5736:92553990:VERBOSE1:token_service.cc(258)] Got an authorization token for mobilesync
[5736:5772:92724214:VERBOSE1:ssl_host_info.cc(113)] Kicking off verification for accounts.google.com
[5736:5772:92731385:VERBOSE1:ssl_host_info.cc(193)] Verification took 7ms
[5736:5736:92980467:VERBOSE1:token_service.cc(280)] Got OAuth2 login token pair

The XMPP connection attempts to talk.google.com all fail with the following, and continue failing:
[5736:5772:90572142:VERBOSE1:login.cc(70)] Starting connection...
[5736:5772:90572437:VERBOSE1:xmpp_connection_generator.cc(65)] XmppConnectionGenerator::StartGenerating
[5736:5772:90572519:VERBOSE1:xmpp_connection_generator.cc(93)] *** Attempting tcp connection to talk.google.com:5222
[5736:5772:90629678:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 2
[5736:5772:91116615:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 4
[5736:5772:91116723:VERBOSE1:single_login_attempt.cc(59)] Error: 4, subcode: 0
[5736:5772:91116782:VERBOSE1:xmpp_connection_generator.cc(93)] *** Attempting ssltcp connection to talk.google.com:443
[5736:5772:91203274:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 2
[5736:5772:91544893:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 4
[5736:5772:91545082:VERBOSE1:single_login_attempt.cc(59)] Error: 4, subcode: 0
[5736:5772:91545180:VERBOSE1:xmpp_connection_generator.cc(93)] *** Attempting tcp connection to talkx.l.google.com:5222
[5736:5772:91745313:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 2
[5736:5772:92701198:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 4
[5736:5772:92701345:VERBOSE1:single_login_attempt.cc(59)] Error: 4, subcode: 0
[5736:5772:92701404:VERBOSE1:xmpp_connection_generator.cc(93)] *** Attempting ssltcp connection to talkx.l.google.com:443
[5736:5772:92878348:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 2
[5736:5772:93415291:VERBOSE1:xmpp_connection.cc(91)] XmppClient state changed to 4
[5736:5772:93415391:VERBOSE1:single_login_attempt.cc(59)] Error: 4, subcode: 0
[5736:5772:93415437:VERBOSE1:xmpp_connection_generator.cc(108)] (10, 0)
[5736:5772:93415493:VERBOSE1:single_login_attempt.cc(127)] Could not resolve DNS: 0
[5736:5772:93415537:VERBOSE1:single_login_attempt.cc(128)] Could not connect to any XMPP server
[5736:5772:93415593:VERBOSE1:xmpp_connection_generator.cc(60)] XmppConnectionGenerator::~XmppConnectionGenerator
[5736:5772:93415642:VERBOSE1:login.cc(117)] Reconnecting in 12 seconds

So it appears there might be a race condition here? If, at the time we make receive the auth request from https://www.google.com/accounts/ClientLogin we don't have the OAUTH token, we give up. On restart though, we'll already have the OAUTH token, so we use it?

Drew, Roger, any thoughts?

Comment 34 by zea@chromium.org, May 22 2012

Attaching the verbose logging I recorded.
chrome
844 KB View Download
Logout/login fixes this problem on R20 2268.23.0.
I suspect this is fallout from r137359 (merged to M20 as r137484) - we will now try to start up sync even if there are no credentials and this will generate an auth error. This behavior is correct on desktop (because we never try to start sync until credentials are loaded, so having sync initialize without credentials is indicative of TokenDB corruption), but it's not correct on cros.

I will work on a patch for this now, but I'll probably need some help from someone on the cros team to test it - we can either merge this patch to M20, or you could roll r137484 out for ChromeOS (I don't think we should roll it out on the desktop chrome branch because this fixes a real issue for desktop users).

Comment 37 by zea@chromium.org, May 23 2012

Owner: atwilson@chromium.org
Reassigning.

To add, I confirmed that in about:histograms of the device I repro'd with, Sync.CredentialsLost was 1, confirming that we were in fact hitting some of the logic added by r137359. I'm fairly confident that for some reason the bogus token we generate due to that patch was triggering the ERR_UNSUPPORTED_AUTH_SCHEME, which gets handled as a permanent error, preventing us from contacting sync until we sign out/back in, at which point the auth controller is recreated and we already have the chromiumsync token at startup.

Comment 38 by ddrew@chromium.org, May 23 2012

We can have this go out on the canary channel both on Chrome & CrOS on 21
first before merging to 20.

Comment 39 by kochi@chromium.org, May 23 2012

Adding my repro cases:

Today on my lumpy device (r136771 canary), I could not repro this on either
wireless (GoogleGuest) or ethernet.  But on Alex, my self-built binary can
reliably repro (at r138192), 100%.

These repros were always like OAuth request error 7 followed by -1/401 errors:

[1100:1100:251266609:WARNING:login_utils.cc(1284)] Failed fetching OAuth request token, error: 7
[1100:2794:251300819:WARNING:syncer_proto_util.cc(171)] Error posting from syncer: Response Code (bogus on error): -1 Content-Length (bogus on error): -1 Server Status: 1
[1100:2794:251300954:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates
[1100:2794:251843705:WARNING:syncer_proto_util.cc(171)] Error posting from syncer: Response Code (bogus on error): 401 Content-Length (bogus on error): 147 Server Status: 4
[1100:2794:251843956:ERROR:download_updates_command.cc(99)] PostClientToServerMessage() failed during GetUpdates

I tried reverting r137359, then I could succeed 7 out of 9 tries, and failed 2 times.
This is better, but still getting OAuth error:7 line.

[8509:8509:1131777820:WARNING:login_utils.cc(1284)] Failed fetching OAuth request token, error: 7

But with r137359 reverted the following -1/401 errors didn't show up.  Sign out and
sign in then sync started working.
Hmmm. Error 7 is "SERVICE_UNAVAILABLE", I guess. I will put a patch together this morning to fix the -1/401 errors, but I think someone on the cros team should figure out why you aren't able to get your OAuth request token.
Labels: Merge-Requested
small change, atwilson's going to merge the fix/change into R20 now.
Project Member

Comment 42 by bugdroid1@chromium.org, May 24 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=138735

------------------------------------------------------------------------
r138735 | atwilson@chromium.org | Wed May 23 21:39:36 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/sync/profile_sync_service.cc?r1=138735&r2=138734&pathrev=138735
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/sync/profile_sync_service_startup_unittest.cc?r1=138735&r2=138734&pathrev=138735

No longer trigger SyncCredentialsLost flow on cros.

On auto_start platforms (cros/android) we no longer start the sync backend until we have a chromiumsync token available.

BUG= 128592 
TEST=Log in on cros, see sync start up.

Review URL: https://chromiumcodereview.appspot.com/10434009
------------------------------------------------------------------------
dharani, if you could approve this I'll merge to m20 later tonight after it bakes a bit on the bots.

Comment 44 by dharani@google.com, May 24 2012

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 45 by bugdroid1@chromium.org, May 24 2012

Labels: merge-merged-1132
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=138739

------------------------------------------------------------------------
r138739 | atwilson@chromium.org | Wed May 23 22:35:11 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/1132/src/chrome/browser/sync/profile_sync_service_startup_unittest.cc?r1=138739&r2=138738&pathrev=138739
 M http://src.chromium.org/viewvc/chrome/branches/1132/src/chrome/browser/sync/profile_sync_service.cc?r1=138739&r2=138738&pathrev=138739

Merge 138735 - No longer trigger SyncCredentialsLost flow on cros.

On auto_start platforms (cros/android) we no longer start the sync backend until we have a chromiumsync token available.

BUG= 128592 
TEST=Log in on cros, see sync start up.

Review URL: https://chromiumcodereview.appspot.com/10434009

TBR=atwilson@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10440007
------------------------------------------------------------------------

Comment 46 by kochi@google.com, May 24 2012

Looks like 401 issue is resolved by Drew's r138735.

I'm still getting SERVICE_UNAVAILABLE error on the first login.
To look into this further I was getting error accessing https://www.google.com/accounts/o8/GetOAuthToken?scope=https://www.google.com/accounts/OAuthLogin&xoauth_display_name=Chromium

On failure case, the URLFetcher was returning no header/body for this request,
and thus GaiaOAuthFetcher class was notifying the error as SERVICE_UNAVAILABLE.

On success case, I was getting HTTP/1.1 200 OK response.

I'll contact GAIA team.
Cc: zelidrag@chromium.org
Owner: kochi@chromium.org
Sending this back to Kochi now that the sync-side issue is fixed (leaving us only with the question about why cros can't load a chromiumsync token). Not sure if maybe Zel is looking at this now instead?
kochi@, we are extracting cookies from this particular request (https://www.google.com/accounts/o8/GetOAuthToken). The page content does not really matter. In this case, we are still properly getting all OAuth1 data out of it, so this is not the issue.

Comment 49 by kochi@chromium.org, May 25 2012

That request returned no content, and more importantly no header (HTTP 200 OK line etc.)
So I guess the connection is reset or something before HTTP starts.

Comment 50 by kochi@chromium.org, May 25 2012

Further investigation showed that network was offline on failure cases.
Probably this is because the first time profile creation for the new user
caused network configuration change (DHCP etc.) and had race condition with
token request.

I'm considering adding retry code on failure path.
http://chromiumcodereview.appspot.com/10446033/

Comment 51 by ddrew@chromium.org, May 25 2012

I'm still reproducing this problem on the latest R20 build 2268.26.0 with Chrome 20.0.1132.17. I just re-imaged my alex machine to this image and logged in with my google.com account. This time I'm on my home wifi network and connected without problems. I'm not using SPDY or any other proxy config at this point, and I didn't enroll the machine on login. 

Comment 52 by kochi@chromium.org, May 28 2012

The CL (http://chromiumcodereview.appspot.com/10446033/) is getting ready but
still needs review.  The change got a bit large and even when I managed to get
it committed to the trunk, I think it would need some bake time before M20 merge,
and it's holiday in US on Monday...

Comment 53 by ddrew@chromium.org, May 30 2012

FYI, I was NOT seeing this problem with today's build 2268.36.0. Sync immediately prompted me (after a re-image) to fill in my password and sync happened immediately. 

Comment 54 by kochi@chromium.org, May 30 2012

Labels: -Merge-Approved -merge-merged-1132 Merge-Requested
Fix committed https://src.chromium.org/viewvc/chrome?view=rev&revision=139461
Let's see how it goes well and merge to M20.

Comment 55 by dharani@google.com, May 31 2012

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged
Status: Fixed
Merged to M20.
http://src.chromium.org/viewvc/chrome?view=rev&revision=139941
Status: Verified
Google Chrome	20.0.1132.27 (Official Build 140692) beta / ChromeOS : 2268.57.0 

Labels: AddAutomatedTest

Comment 59 by kochi@chromium.org, Jun 14 2012

Issue chromium-os:31592 has been merged into this issue.

Comment 60 by ddrew@chromium.org, Jul 10 2012

Labels: -Noteworthy
Project Member

Comment 61 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 62 by bugdroid1@chromium.org, Mar 9 2013

Labels: -Type-Regression -Area-UI -Feature-Sync -Mstone-20 Type-Bug-Regression Cr-Services-Sync Cr-UI M-20
Project Member

Comment 63 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment