Andy McKay Reporter
	Description • 8 years ago

Allow an add-on to open the devtool panel programmatically. This was requested by adblock plus. I'll let Wladimir add some details of how/why.

	Wladimir Palant
	Comment 1 • 8 years ago

We plan to use a devtool panel for our "blockable items" information which makes sense. However, users won't necessarily find/expect this functionality in the devtools. So ideally we would still have "Open blockable items" in the extension's menu - but for that the extension needs the ability to open its devtool panel programmatically (Chrome APIs don't allow that).

	Andy McKay Reporter
	Comment 2 • 8 years ago

Luca, I think you had a prototype for this? Is this straightforward when the rest of devtools lands?

	Luca Greco [:rpl] [:luca] [:lgreco]
	Comment 3 • 8 years ago

(In reply to Andy McKay [:andym] from comment #2)
> Luca, I think you had a prototype for this? Is this straightforward when the
> rest of devtools lands?

yeah, I started to prototype it using a webextensions experiment (https://github.com/rpl/webext-experiment-devtools):

Opening the devtools toolbox on one of the existent devtools panels is pretty straightforward, what is going to be more tricky is to be able to select a custom devtools panel registered by an addon (even registered by the same addon that calls the proposed `openDevTools` API method).

The reason is that the "addon registered panel" doesn't exist until the addon devtools_page creates it (which should usually happen just after the devtools toolbox has been completely loaded, at least if the devtools page does not miss to create the panel for any reason, a bug or for intentional reasons).

One option here could be (once the toolbox is open) to wait for a short amount of time and switch to the first panel created by the addon that has opened the toolbox, if it has been registered, but if the addon fails to create its panel, it would be probably confusing for the users, because it would not be completely clear "why developer toolbox has been opened".

Given that this particular feature is not supported on Chrome, a better strategy could be:

- support an additional devtools_panel (or devtools_panels) property in the manifest, which will statically register a devtools_panel

- return a rejected promise from the `openDevTools` API method if the addon is trying to open the toolbox on a custom devtools panel that is not already registered (and do not open the toolbox at all in that case)