1722709 - nsIWorkerDebuggerManager doesn't report existing workers when navigating back to a bfcached page

Status: NEW

(DevTools :: General, defect)

Description

[Alexandre Poirot [:ochameau]]

This make the following test to fail intermittently with Fission:
https://searchfox.org/mozilla-central/rev/a9db89754fb507254cb8422e5a00af7c10d98264/devtools/shared/commands/target/tests/browser_target_list_tab_workers_bfcache_navigation.js#104-110
We do not get the worker targets when navigating back.

I tracked it down to this code:
https://searchfox.org/mozilla-central/rev/a9db89754fb507254cb8422e5a00af7c10d98264/devtools/server/connectors/js-window-actor/DevToolsWorkerChild.jsm#248

  Array.from(wdm.getWorkerDebuggerEnumerator())

which doesn't report any worker.
It seems to be even more frequent when enabling the server targets.

In bug 1721991, I'll disable these assertion on fission, so that we can investige this failure over here.

It doesn't seem to be an error within DevToolsWorkerChild, we seem to be trying to fetch the workers correctly ? We would need to verify that's the right DevToolsWorkerChild trying to fetch workers, I haven't verify that. We should also verify that the workers do run fine when navigating back. i.e. verify that bfcacheInParent did not break them.
Reminder: this only fails with fission/bfcacheInParent.
But this may relate to the assertions we are hitting in bug 1721859. There might be something broken in WorkerPrivate.cpp/WorkerDebugger.cpp.

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

I fixed the intermittent in Bug 1721991 and it wasn't failing because of the workerDebuggerManager (wdm), but only because we were trying to use gBrowser.goBack() to soon after doing a navigation. So the actual page we would be one was the "away" data url (https://searchfox.org/mozilla-central/rev/a9db89754fb507254cb8422e5a00af7c10d98264/devtools/shared/commands/target/tests/browser_target_list_tab_workers_bfcache_navigation.js#96) , which doesn't have any worker, so it makes sense that the wdm wasn't reporting anything here.

While doing my investigations, I added quite some logs around platform code for workers, and once I fixed the test, I didn't see wdm misbehaving.
I'll check Bug 1721859 to see what's the issue with debug builds (and if does related to an issue with wdm