Open Bug 1370362 Opened 7 years ago Updated 2 years ago

browser toolbox should also include devtools webextensions

Categories

(DevTools :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: clarkbw, Unassigned)

References

(Blocks 1 open bug)

Details

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)?
Flags: needinfo?(lgreco)
Priority: -- → P2
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).
Flags: needinfo?(lgreco)
Severity: normal → enhancement
Priority: P2 → P3
Product: Firefox → DevTools

Also added to the backlog for prioritization.

Sounds like this can happen on an opt-in basis; given that browser-toolbox is for an advanced audience this is reasonable decision to put on those users.

Luca, how does this look like 2 years after your last comment?

Flags: needinfo?(lgreco)

Luca, how does this look like 2 years after your last comment?

Most of what described in my last comment (comment 2) is still true, the only thing that changed in the meantime is related to WebExtensions debugging:

  • as part of Bug 1525533, the "new about:debugging" page is going to connect the debugger to local add-ons without using the Browser Toolbox

and this should make it slightly simpler to allow, on a opt-in basis, a devtools extension to be used to inspect another extension page, because in the toolbox will be running in the same profile where the devtools WebExtensions is installed,
but the target extension page should be opened in a Firefox tab (mainly because, as described in comment 2, the existing devtools extensions are usually injecting a content script in the target page and exchanging messages between the devtools panel and the content script, and so if the target is in the tab it will be easier to make the devtools extension able to work unmodified on these "opt-in" targets).

For the "browser toolbox" scenario, every one of the problems described in my last comment are still true, in particular:

  • the browser toolbox runs in a separate process and Firefox profile:
    how we decide which extensions to install and enable in the "browser toolbox process" profile?
    How are these extension disabled/uninstalled and upgraded in the "browser toolbox process" profile?

  • the target of a browser toolbox is going to always be remote:
    how do we allow the devtools extension installed in the browser toolbox profile to inject a script in a remote target?
    how do we allow the script injected in the remote target to exchange messages with the devtools extension running in the browser toolbox process?
    (the extensions devtools panel are currently using the extension messaging APIs and the tabId to direct its messages
    to the content script running in the target tab)

A slightly easier way to make it possible to inspect part of the devtools toolbox with a devtools extension may be the following:

  • allow a devtool extension, on an opt-in basis (and maybe only on non-release channels), to attach a content script to tabs pointed on the url used to open the entire devtools toolbox in the tab (which should be "about:devtools-toolbox" if I recall correctly).

Would be this last strategy enough to cover the needs briefly described by Mike in Bug 1535578 comment 0?

Flags: needinfo?(lgreco)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.