The crappy wifi at SFO redirects me back to the captive portal after a while of browsing the interwebs. If a sync is happening in the period before I unlock it again by clicking the Whatever button in the captive portal, it errors with an Unkonwn Error. Excerpt from log: 1300236063004 Service.Main INFO Starting sync at 2011-03-15 17:41:03 1300236063004 Service.Main INFO In sync(). 1300236063004 Service.Main DEBUG Clearing sync triggers. 1300236165463 Net.Resource DEBUG GET success 200 https://phx-sync091.services.mozilla.com/1.0/philikon/info/collections 1300236165477 Service.Main DEBUG Exception: info.obj is null JS Stack trace: ()@service.js:1746 < WrappedNotify()@util.js:172 < WrappedLock()@util.js:140 < _lockedSync()@service.js:1695 < ()@service.js:1686 < WrappedCatch()@util.js:114 < sync(false)@service.js:1667 < ([object Object])@service.js:596 < notify([object XPCWrappedNative_NoHelper])@util.js:1185 This should be reported as a network error so that our error reporting stuff knows how to deal with it.

We've seen "info.obj is null" at very infrequent intervals for as long as I've been working on Sync... including at the Mountain View office, and at home. (You might recall a n00b named Richard putting a workaround in one of his first patches!) It thus cannot be just a captive portal issue, though that might be the easiest way to prompt the error. A good solution should spot this condition inside Resource, rather than returning a valid-but-broken response -- info.obj being lazy. We should also check that we're checking all of the necessary success flags when we fetch info/collections; I'm not sure we do. Finally, it might be worthwhile revisiting Bug 623080...

See also: Bug 587956.