Bug 1539071 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

After investigating a bit, this is the combination of several issues. They are not related to a particular panel being async, the whole toolbox destroy being async is the problem here.

The first issue is that the devtools's map `_toolboxes` is updated too late.

When we reload the page, devtools.js::showToolbox will check if the target already has a toolbox:
https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/devtools.js#455 

But the entry in the map is only cleared when toolbox fires the "destroyed" event, which is almost the last step of the async destroy.
https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/devtools.js#554-557
https://searchfox.org/mozilla-central/rev/a7315d78417179b151fef6108f2bce14786ba64d/devtools/client/framework/toolbox.js#3048

So instead of creating a new Toolbox we try to reuse the one that is being destroyed. 

If we fix that, by invalidating the entry in the map earlier or any other workaround, then we have a second issue. When debugging remote clients, we are always reusing the same client (to avoid connection prompts). But if we use the same client, we will also get the same target fronts when we ask the front for a debug target. The toolbox destroy is also destroying the target front at the end of its destroy:
https://searchfox.org/mozilla-central/rev/a7315d78417179b151fef6108f2bce14786ba64d/devtools/client/framework/toolbox.js#3046

But when we try to get the target after the reload,
https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/toolbox-init.js#110
https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/target-from-url.js#65

the target has not been destroyed yet, so `client.mainRoot.getTab({ outerWindowID: id });` will return the target front instance that is about to be destroyed. This second issue would also not occur if the toolbox destroy was synchronous.

I will post a workaround to illustrate this. The correct fix is definitely to make everything in the destroy sequence for the toolbox synchronous.
After investigating a bit, this is the combination of several issues. They are not related to a particular panel being async, the whole toolbox destroy being async is the problem here.

The first issue is that the devtools's map `_toolboxes` is updated too late.

When we reload the page, devtools.js::showToolbox will check if the target already has a toolbox:
[client/framework/devtools.js#455](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/devtools.js#455) 

But the entry in the map is only cleared when toolbox fires the "destroyed" event, which is almost the last step of the async destroy.
[client/framework/devtools.js#554-557](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/devtools.js#554-557)
[client/framework/toolbox.js#3048](https://searchfox.org/mozilla-central/rev/a7315d78417179b151fef6108f2bce14786ba64d/devtools/client/framework/toolbox.js#3048)

So instead of creating a new Toolbox we try to reuse the one that is being destroyed. 

If we fix that, by invalidating the entry in the map earlier or any other workaround, then we have a second issue. When debugging remote clients, we are always reusing the same client (to avoid connection prompts). But if we use the same client, we will also get the same target fronts when we ask the front for a debug target. The toolbox destroy is also destroying the target front at the end of its destroy:
[client/framework/toolbox.js#3046](https://searchfox.org/mozilla-central/rev/a7315d78417179b151fef6108f2bce14786ba64d/devtools/client/framework/toolbox.js#3046)

But when we try to get the target after the reload,
[client/framework/toolbox-init.js#110](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/toolbox-init.js#110)
[client/framework/target-from-url.js#65](https://searchfox.org/mozilla-central/rev/3d469329a42644b41e66944d8da22d78d8c0f5ec/devtools/client/framework/target-from-url.js#65)
The target has not been destroyed yet, so `client.mainRoot.getTab({ outerWindowID: id });` will return the target front instance that is about to be destroyed. This second issue would also not occur if the toolbox destroy was synchronous.

I will post a workaround to illustrate this. The correct fix is definitely to make everything in the destroy sequence for the toolbox synchronous.

Back to Bug 1539071 Comment 2