I don't know if this is an issue with DevTools or with the way the WebExtensions API implements adding a new panel, but I just tried an addon that added a new panel to DevTools, and it took so long to load when I opened DevTools, that I thought something was not working (until it then showed up on the toolbar). I loaded the addon with the about:debugging method. It was this addon: https://github.com/devtools-html/extension-examples/blob/master/devtools-panel I wonder if this delay can be reduced somehow.

Hi :sole, The panel is not yet loaded when it appears in the devtools toolbox (at that time the new devtools panel has been registered to the toolbox and it is actually loaded only when it is selected the first time). The addon "devtools_page" manifest property defines which page from the addon package is going to be the entrypoint for the devtools toolbox customizations, and they are currently created when the internal "toolbox-create" devtools event is fired[1] (and they are destroyed on the "toolbox-destroy" event[2]), and so most of the "time to show the addon devtool panel" latency is more likely to be related to the "devtools page waiting for the toolbox to be created". The devtools page is currently loaded and executed when the toolbox has been created and it is ready for more custom panel to be added to it, so that the custom devtools panel can be defined using the "devtools.panels.create API" method. Nevertheless, I agree that this latency time can be perceived from a user as actual loading time for the panel, and so I'm going to investigate how much we can reduce it. [1] http://searchfox.org/mozilla-central/rev/a5c2b278897272497e14a8481513fee34bbc7e2c/browser/components/extensions/ext-devtools.js#262 [2] http://searchfox.org/mozilla-central/rev/a5c2b278897272497e14a8481513fee34bbc7e2c/browser/components/extensions/ext-devtools.js#284

Hi :sole, I tried the addon linked above and it seems to show up pretty fast, may I ask you if you tried it on profile with any other extension that could have introduced an higher latency that I was able to reproduce? I'm going to try to apply on the devtools page the same kind of pre-loading that we use on the extensions popup windows to try to speed up it a bit, but at the same time I also want to be sure that I'm looking at the same issue that you saw.

I don't know if I have extensions that introduce latency... as far as I know I do not have any DevTools extension installed right now. What I do know is that my laptop is not 'super fast', so it will amplify the effects of slow code. I made a video so you can see how it looks like: https://www.youtube.com/watch?v=dLvsTqmHWuY :-) The DevTools tab bar is rendered first, then you can see it takes almost 1 second after that for the extension panel tab to be displayed on the tab bar. I'm using the very latest version of Nightly. Does this help?

A huge number of kudos go to the GeckoProfiler: a brief session with it has been enough to figure out where we are actually spending the time while we are waiting the devtools panel defined from a WebExtension's devtools page to show up. In the current implementation we are waiting that the "ready" event is fired by the toolbox before we actually register the panel definition to the toolbox (which is when the panel tab can become visible in the toolbox), which means that we are waiting the toolbox to be fully loaded and rendered. I've prepared a patch with a small amount of changes to both the DevTools toolbox internals and to the WebExtensions devtools.panels.create internals, so that we register the definition immediately after the toolbox "create" event, which makes the tab of the new panel is immediately visible when the toolbox is rendered the first time (and then, internally to the toolbox itself, we can defer the actual "panel container building" phase to when the toolbox is actually "ready"). This makes seems to be enough to make the tab of a WebExtensions devtools panel able to show up without any "user perceivable" lag time.

Pushed to try here: - https://treeherder.mozilla.org/#/jobs?repo=try&revision=9efaeecdb12d020687a8b60ada5d278c6793289f Hi :sole, do you mind give a try to the build attached in the treeherder link to check that the latency is gone as in my local tests?

Comment on attachment 8875757 [details] Bug 1347108 - Reduce the amount of time to show up a WebExtensions DevTools panel. Hi Brian, can you take a look at the DevTools toolbox bits from this patch for an initial feedback?

Comment on attachment 8875757 [details] Bug 1347108 - Reduce the amount of time to show up a WebExtensions DevTools panel. https://reviewboard.mozilla.org/r/147182/#review151376 ::: devtools/client/framework/toolbox.js:1393 (Diff revision 2) > + > this.additionalToolDefinitions.set(definition.id, definition); > this.visibleAdditionalTools = [...this.visibleAdditionalTools, definition.id]; > > + if (this.isReady) { > - this._combineAndSortPanelDefinitions(); > + this._combineAndSortPanelDefinitions(); I don't see why this call was here before the patch, since the setter on visibleAdditionalTools which fires immediately before calls it. So I believe `_combineAndSortPanelDefinitions` can be removed here. And also it should be removable in the ready callback below since it's called in the setter for `panelDefinitions`, which happens during toolbox open before ready is emitted. Can you please confirm if this is right? If so, we only need to call `_buildPanelForTool` in both of these conditions.

Comment on attachment 8875757 [details] Bug 1347108 - Reduce the amount of time to show up a WebExtensions DevTools panel. https://reviewboard.mozilla.org/r/147182/#review151376 > I don't see why this call was here before the patch, since the setter on visibleAdditionalTools which fires immediately before calls it. So I believe `_combineAndSortPanelDefinitions` can be removed here. And also it should be removable in the ready callback below since it's called in the setter for `panelDefinitions`, which happens during toolbox open before ready is emitted. > > Can you please confirm if this is right? If so, we only need to call `_buildPanelForTool` in both of these conditions. I give it a try (but making the change, running the existent tests and by also trying an extension with a devtools panel manually) and everything seems to work correctly by deferring the `_combinaAndSortPanelDefinitions` to when the `visibleAdditionTools` setter is called. I'm going to push it to try to be check that it doesn't make some other tests that I've not executed locally to fail.

Comment on attachment 8875757 [details] Bug 1347108 - Reduce the amount of time to show up a WebExtensions DevTools panel. Added r? assigned to Andrew (for the bits in the WebExtensions internals) and Brian (for the bits in the DevTools internals).

Comment on attachment 8875757 [details] Bug 1347108 - Reduce the amount of time to show up a WebExtensions DevTools panel. https://reviewboard.mozilla.org/r/147182/#review154670 I don't see anything wrong in the webextensions code, but I can't really assess any risks or problems that would come from adding the panel before the toolbox is ready. I assume bgrins will evaluate that.

Comment on attachment 8875757 [details] Bug 1347108 - Reduce the amount of time to show up a WebExtensions DevTools panel. https://reviewboard.mozilla.org/r/147182/#review155364

Pushed by luca.greco@alcacoop.it: https://hg.mozilla.org/integration/autoland/rev/823276a452b6 Reduce the amount of time to show up a WebExtensions DevTools panel. r=aswan,bgrins

Luca, finally had a chance to look at this! I can't notice that very visible delay anymore. If there's a delay on adding the panel, it's invisible for me now-the entire tabs seem to be shown at the same time. Very good work! Thank you :)

In an add-on for Firefox 60 (testing with web-ext), I'm seeing very delayed load times in a panel window my add-on creates (same with popup or detached_panel, though using a normal window doesn't have the problem), a delay which is only remedied by resizing the window or right-clicking in it...