[Sources] Should see extensions more clearly

[julienw]

STR:

1. Install React Addon from https://addons.mozilla.org/en-US/firefox/addon/react-devtools/
2. Install UBlock Origin from https://addons.mozilla.org/fr/firefox/addon/ublock-origin/
3. Go to any page, for example www.mozilla.org
4. Open the debugger
5. Expand the "moz-extension://" line in the "sources panel"
   => The 2 extensions are mixed, we see the React addon's build and ublock's js directories glued together.
   We don't know which extensions all this come from.

Instead, we should likely have a different top-level line for each extension, with the extension's name.

You can also see the part with resource:// at the end. I'm not sure why we see this either, is it because some code from this resource has been run or injected?

[jasonLaster]

@julienw can you share some screenshots of the current behavior

[julienw]

I added a screenshot in the initial description. This is from www.mozilla.org with both ublock origin and the react addon enabled. I also added a line about the part in resource://.

[jasonLaster]

Hey @rpl, @digitarald i'm curious what you think?

We probably have other similar issues too

[rpl]

I definitely agree (and I recall that we had already briefly discussed about this before, I'm been wondering if we were discussing about a particular issue already fined and I've been looking for it, e.g. #5759 seems to be also a duplicate of it, but it has been filed just 8 days ago and so it isn't the reason why I recall that we talked about this before).

I'm pretty sure that to be able to show the extension name we have to make some changes on both:

• the remote debugging actors side (e.g. to be able to collect the extension name related to the moz-extension url, we can use WebExtensionPolicy.getByURI, https://searchfox.org/mozilla-central/rev/57bbc1ac58816dc054df242948f3ecf75e12df5f/dom/chrome-webidl/WebExtensionPolicy.webidl#146,153,160, to retrieve the extension policy object that represents the installed extension on the debugging server side and then extensionPolicy.name will be its user-visible name, https://searchfox.org/mozilla-central/rev/57bbc1ac58816dc054df242948f3ecf75e12df5f/dom/chrome-webidl/WebExtensionPolicy.webidl#41, and extensionPolicy.id its AMO/manifest extension id)

• the debugger client UI side (to render the tree of the extension files into a new "extension" level, which can use the extension name as its label, and maybe show the extension id and its hostname in a tooltip when hovered?).

Maybe we could even start by adding the new "extension" level in the source tree and use the moz-extension hostname as a first step (so that at least a developer that already knows the moz-extension hostname of the extension, e.g. by looking the one visible in about:debugging#addons, is able to find the files of that extension more easily, and then improve it further by showing the user-visible extension name as a second step, once we landed the changes on the remote debugging server side, and maybe also degrade gracefully when the remote target version doesn't yet provide this additional information about the sources listed in the tree).

About the resource:// urls, I'm pretty sure that ExtensionContent.jsm is there because of some content script code injected as a string using tabs.executeScript, which are currently evaluated into the content scripts sandbox without any custom url, and so any error raised from that evaluated code is currently recognized as coming from resource://gre/modules/ExtensionContent.jsm (which is where the Cu.evalInSandbox is triggered: https://searchfox.org/mozilla-central/rev/57bbc1ac58816dc054df242948f3ecf75e12df5f/toolkit/components/extensions/ExtensionContent.jsm#493), sometimes ago I filed an issue about this and attached a set of proposed patches: https://bugzilla.mozilla.org/show_bug.cgi?id=1410932 (in particular this patch was a proposed change that would fix that issue: https://reviewboard.mozilla.org/r/192080/diff/2#index_header),
unfortunately after an initial round of review comments (and one of the patches already r+), I've never been able to get a new review on the last updates I've applied on it :-(

[darkwing]

Using the addons icon instead of the globe would be awesome too

[julienw]

@jasonLaster In my initial description, I wrote that we should see the extension's name. Currently we see the extension URL:

This is better than before, but still not useful enough in my opinion.

Should I file a separate bug or should we reopen this one ?

[jasonLaster]

@julienw i think this should be filed in bugzilla as the work will largely be server-side. CC @juliandescottes who might know more about addons

[juliandescottes]

Not sure where the server is getting the addon uuid, but you could use the WebExtensionPolicy to convert from moz-extension:// to the addon name:

const uri = "moz-extension://4ade278d-b4ba-1c45-9398-7d33741c5aa6/";
const name = WebExtensionPolicy.getByURI(Services.io.newURI(uri)).name;

This is just from a quick search in our codebase, @rpl might know a better way.
But the source actor already seems to be doing some logic around this in _mapSourceToAddon (check how it is using mapURIToAddonID).

[julienw]

Thanks, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1486416