When using a framework like https://github.com/ivantsov/redux-webext/ (Redux over WebExtensions) it would be useful for the Redux DevTools WebExtension to be available in the [ debug ] or browser toolbox mode. Right now those DevTools extensions are only loaded in the devtools toolbox. STR: 1. Install Redux WebExtension https://addons.mozilla.org/en-US/firefox/addon/remotedev/ 2. Open Example Redux WebExtension application https://github.com/ivantsov/redux-webext/tree/master/examples 3. Use [ debug ] button from about:debugging 4. Don't find the Redux DevTools panel Expected: For 4, I hope to find the redux devtools extension loaded in the browser toolbox so I would also have time travel debugging when working with my web extensions.

This sounds important for us as a dogfooding practice. Luca, do you mind guiding us on the necessary changes to make DevTools webextensions work in the browser toolbox (or in the addon debugging toolbox)?

Yes, I'm absolutely happy to! Here is some initial details about the issues (at least the one that we already know about) to keep into account while planning this. The WebExtensions devtools APIs that we have already landed use the RDP protocol to exchange messages with the Remote Debugging Server actors, which is good because it is one step in the right direction. Nevertheless there are still a bunch of issue that needs to be discussed to agree on a strategy: 1. The BrowserToolboxProcess, which is currently used for both the Browser Toolbox and the Addon Debugging Toolbox, runs in a different process (actually it is a totally different "Firefox" instance) and on a different profile, and so the "devtools addons webextensions" installed in the Firefox instance are not (at least not yet) available (or enabled) in that toolbox process. 2. Most of the commonly used "devtools addon webextensions" (e.g. the React and Redux DevTools) usually attach a content script to the inspected window (the target of the toolbox) and then they exchange messages between the devtools panel and the content script, by using the WebExtensions messaging APIs and a background page. About (1), something that can help on a subset of the possible scenarios is Bug 1373219: we can more easily enable a "devtools addon webextension" on the Addon Debugging toolbox if we open it as a regular ("in-process") toolbox instead of using the BrowserToolboxProcess, which is going to be possible for the WebExtensions that run in oop mode. (and I've already a patch for it, that I prepared while working on Bug 1302702, I removed it from Bug 1302702 and deferred to a follow up because Bug 1302702 was already a big change on its own) Unfortunately this will not help the following "addons"-related scenarios (where the target is running in the main process): - we still need to use the BrowserToolboxProcess for the webextensions addons that are not running in oop-mode (in other words, all the webextensions addons until we enable the oop-mode) - we will still need to use the BrowserToolboxProcess for any addon that uses legacy addon technologies (e.g. any hybrid addon with an embedded webextension, system addons based on legacy technologies) Also, about (1), if we want to enable a "devtools addon webextension" on the Browser Toolbox (when the target is the entire browser), we need also to decide: - when a "devtools addon webextension" can be reasonably allowed to run in a the Browser Toolbox? (e.g. only on non-release channels? only when a defined preference is switched to true), mostly because if the target is the entire browser (or another privileged part of the browser) the "devtools addon webextension" is basically going to be able to escape its "security sandbox" (e.g. it is probably ok when the user is a developer and he knows what he is doing, but it is probably not ok if we extend it to the general user population by default). About (2), one thing that we have to decide is how we will allow a "devtools addon webextension" to exchange messages with the target when the target is not a tab and the "devtools addon webextension" content script cannot be attached to it (e.g. we don't allow an extension to attach a content script on windows that are not webpages loaded in a regular tab, also we have to keep into account that two different Firefox "instances" are involved when the "devtools addon webextension" is running in a BrowserToolboxProcess).