Bugzilla

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #84)
> (In reply to Jens Stutte [:jstutte] from comment #83)
> I'm not sure I'm parsing you correctly here, but if this was related to loading the top-level script via Blob URL, we would expect to see a ["ScriptLoader" StrongWorkerRef](https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/workers/ScriptLoader.cpp#499).

That seems not to be the [`WorkerDebuggeeRunnable::mSender`](https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/workers/WorkerRunnable.cpp#716-717) mentioned in the last line of the log, though.

> I think the Busycount being 1 suggests that something like [the ParentStatus check we were going to address in another patch by chaning to >= Killing or similar](https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/workers/WorkerPrivate.cpp#1582)[1] is failing a dispatch to the worker and the runnable is getting leaked and so the workerref is never released.  Bug 1800659 will potentially help with that, but may not end up addressing the ParentStatus check.

This would also apply to any `WorkerDebuggeeRunnable`, and in particular the `MessageEventRunnable`, see also bug 1769913 for an earlier suspect.

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #84)
> (In reply to Jens Stutte [:jstutte] from comment #83)
> I'm not sure I'm parsing you correctly here, but if this was related to loading the top-level script via Blob URL, we would expect to see a ["ScriptLoader" StrongWorkerRef](https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/workers/ScriptLoader.cpp#499).

IIUC then the `blob:null/ecd76e1a-8290-4598-8cb2-e5d8e5cb235a` is just the "fake" URL of the blob that contains our worker JS. A stronger hint might be the last line of the log pointing to the [`WorkerDebuggeeRunnable::mSender`](https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/workers/WorkerRunnable.cpp#716-717) ref.

> I think the Busycount being 1 suggests that something like [the ParentStatus check we were going to address in another patch by chaning to >= Killing or similar](https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/workers/WorkerPrivate.cpp#1582)[1] is failing a dispatch to the worker and the runnable is getting leaked and so the workerref is never released.  Bug 1800659 will potentially help with that, but may not end up addressing the ParentStatus check.

This would also apply to any `WorkerDebuggeeRunnable`, and in particular the `MessageEventRunnable`, see also bug 1769913 for an earlier suspect (already linked to bug 1800659, too).