1364323 - 0.91ms uninterruptible reflow at waitForSyncCallback@resource://gre/modules/services-common/async.js:98:7

Status: RESOLVED INVALID

(Firefox :: Sync, defect)

Description

[Hazel Ward]

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

Comment 1

[Mark Hammond [:markh] [:mhammond]]

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.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

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

Comment 3

[Mike Conley (:mconley) (:⚙️)]

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.