Here's the stack: waitForSyncCallback@resource://gre/modules/services-common/async.js:98:7 makeSpinningCallback/callback.wait@resource://gre/modules/services-common/async.js:168:27 promiseSpinningly@resource://gre/modules/services-common/async.js:234:12 _fetchServerConfiguration@resource://services-sync/service.js:855:24 _remoteSetup@resource://services-sync/service.js:880:10 sync@resource://services-sync/stages/enginesync.js:86:11 onNotify@resource://services-sync/service.js:1080:7 WrappedNotify@resource://services-sync/util.js:161:21 WrappedLock@resource://services-sync/util.js:117:16 _lockedSync@resource://services-sync/service.js:1070:12 sync/<@resource://services-sync/service.js:1062:7 WrappedCatch@resource://services-sync/util.js:92:16 sync@resource://services-sync/service.js:1051:5

huh - this stack points at a nested event loop we spin (yeah, I know, bug 1007448) while waiting for an async network fetch and getting a tiny response. Is it possible these nested event loops are causing mis-attribution? Eg, we have issues with the profiler/debugger in that any code run indirectly via that event loop looks like it comes from sync, and while this looks a bit different to that, it might still be a complication.

oops - meant to paste http://searchfox.org/mozilla-central/rev/cd8c561106d804e26bc09389f18f361846d005eb/services/common/async.js#98 as the event loop.

Oh no! Reflow! can't tell the difference between a JS-caused reflow, and a reflow that's occurring natively while spinning a nested event loop in JS, which I think is what's happening here. I'll see if I can alter Oh no! Reflow! to detect this difference, but for now, closing this as INVALID.