STRs:

• go to about:debugging-new
• connect to a remote runtime (android, local Firefox desktop, doesn't matter)
• select the runtime
• click on inspect for any tab of this runtime
• in the about:devtools-toolbox that opened, enable Performance panel if needed
• select performance panel
• close this about:devtools-toolbox tab
• in about:debugging-new click on inspect for this tab again

ER: A new tab open should open with a valid toolbox
AR: A blank tab is opened. This will only be fixed by destroying the client, or removing the tab on the device. Happens only with the old performance panel.

We have this issue because the old performance panel has an async destroy that relies on promises from the panel's document. If the document is destroyed before the panel is destroyed, the promise never resolve, and the destroy of the toolbox gets stuck.

This issue also affects devtools docked in a separate window with the usual STRs

• set dock mode to separate window
• open devtools
• select old Performance panel
• close devtools
  => devtools can no longer open for this tab

Here is my plan for this :

• make sure the destroy of the performance panel uses promises from the browserLoader
• add a failsafe mechanism in the toolbox so that we avoid getting stuck on panel destroy calls (or at least we get a nice error)

The main goal is to use the browser loader instead of script tags to avoid using promises tied to the document during the panel's destroy.
I tried to cleanup a bit the modules, to rely less on globals and more on explicit require calls, but there is room for improvement left.
I will write an additional test to check that toolboxes in WINDOW hosts can be closed and reopened for any of our panels in a second changeset.

Try at : https://treeherder.mozilla.org/#/jobs?repo=try&author=jdescottes%40mozilla.com&selectedJob=228504476

One unrelated permafail on sw-e10s jobs, green otherwise.

I am giving up on the automated test for now. Triggering the issue is very tricky. On OSX on my machine, it only happens when closing the toolbox window with the "close" button. Closing it with a keyboard shortcut will not trigger it. Closing it using window.close() will not trigger it either. I could not find any way to simulate a similar "closing sequence" from the test.

I tried slowing down the toolbox destroy to trigger similar issues, but the first part of the toolbox really needs to have a window object still valid, too much code depends on it. I tried using executeSoon to "block" the event loop before resuming the async calls in the perf panel destroy, to no avail.

I don't think I am going anywhere with this at the moment.

https://hg.mozilla.org/mozilla-central/rev/cb15b108719a