Captive portals can cause unknown error



Cloud Services
Firefox Sync: Backend
7 years ago
3 years ago


(Reporter: philikon, Unassigned)


(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [captive portal])

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
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.
Depends on: 562917
Depends on: 816866
No longer depends on: 816866
You need to log in before you can comment on or make changes to this bug.