642031 - Captive portals can cause unknown error

Status: NEW

(Firefox :: Sync, defect)

Description

[Philipp von Weitershausen [:philikon]]

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.

Comment 1

[Richard Newman [:rnewman]]

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...

Comment 2

[Richard Newman [:rnewman]]

See also: Bug 587956.