Looking at Bug 1070066 today, I found an interesting issue. Pretty much everywhere in gaia, it's assumed that the settings API will never fail on a query call. There's lots of calls to mozSettings.createLock().get()/set() that just expect to get back a DOMRequest no matter what.
The problem in bug 1070066 is that the call screen app closes itself before all of its callbacks are done, meaning that settings API calls are made after inner-window-destroyed. These fail in what look like settings issues, which it partially is, since the settings API is trying to create a DOMRequest with no window. This was true for the old API, and is true for the new one too. If we don't have a window, you're not getting back a DOMRequest. You're getting an exception. Unfortunately, in terms of bug 1070066, it's getting fixed by things like bug 1068109, where we just put in a 2 second wait for UX reasons that also happens to fix this. Great bandaid, and needed for UX, not actually a fix for the API problem. So, we need to figure out what to do here. Almost all settings API calls in gaia are queries chained to createLock(), which means there's no error checking, and they'll throw exceptions, possibly leading to odd state issues like Bug 1070066. I've filed bug 1073259 to at least make the errors more descriptive, though they'll also look even more like settings errors so I look forward to lots more bugs filed against me. Going forward, what should we do here? Document better and try to wrap all current instances in try/catch? Return fake DOMRequest-like objects that instantly fail? _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
