Robert Helmer [:rhelmer] Reporter
	Description • 8 years ago

Right now built-in system add-ons (hello, pocket, e10srollout, etc) are listed alongside others in about:debugging

This can be confusing for people when new system add-ons ship.

These should be in a separate list in about:debugging, or at least have some kind of indicator (maybe the word "built-in"?) next to them.

	Robert Helmer [:rhelmer] Reporter
	Comment 1 • 8 years ago

The way to detect this is via the public AddonManager API is to check addon.isSystem

	Andy McKay
	Comment 2 • 8 years ago

If anyone is looking at this, maybe bug 1245717 could be fixed on the way.

	Jan Keromnes [:janx]
	Comment 3 • 8 years ago

I agree that this can be confusing to add-on developers.

Maybe a good way to fix this would be to separate add-ons into different categories, like the workers in about:debugging#workers?

Today, all add-ons are listed under the single category "Extensions", but instead we could have several categories, e.g.:
- WebExtensions
- Temporary Add-ons (would fix bug 1245717)
- Restartless Add-ons
- SDK Add-ons
- Overlay Add-ons
- System / built-in Add-ons

Luca, do these categories make any sense? (I'm still very confused by all the different add-on types we have.) And would you be interested in addressing or mentoring this bug?

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

I completely agree, the about:debugging#addons panel is currently very crowed.

and yes, I'm absolutely interested, to address this bug or to mentor it (I'm always happy when I can help someone to make his first steps into a component that he would like to work on).

About the categories:
the above categories seems right to me, but I'm a bit concerned that they are too many categories, and they could end up to be confusing even if they are the real actual categories.

here is a small list of caveats/related issues that could be useful to consider:

- WebExtension will be easily recognizable once we land Bug 1285556

- SDK Add-ons are Restartless Add-ons, if I remember correctly currently we are not able to say if an addon is a Restartless because it is an SDK one or a plain bootstrap restartless addon, at least not based on the properties/getters currently available in the AddonWrapper 

- in my own opinion Overlay Add-ons are more easily debuggable using the BrowserToolbox, because they have no clear entrypoint context that we can consider their preferred debug global, but they blend themselves in the browser internals, and (if I'm not wrong) they are not currently visible in the "about:debugging#addons"

- System / built-in Add-ons are always installed, but they are probably an interesting debugging target only internally

And so, long story short, here is my proposal:

- split addons into 3 categories: WebExtensions, Legacy (or Classic, if we don't like to use "legacy" as the section title), System

- show/hide the System Addons section based on a defined preference (e.g. "devtools.addons.filter.system-addons" or "devtools.addons.show-system-addons", maybe the preference can be set to make them visible by default on Nightly)

how it sounds to you?

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

To make temporarely installed addons more visible, without turning them into a separate category (section of the about:debugging#addons panel), 
how about ordering the addons list so that the temporarely installed addons are always on the top of their list?

	Andy McKay
	Comment 6 • 8 years ago

The categories sound good to me. We could maybe do temporary add-ons as a seperate colour, or just a message eg: "Temporarily installed" since they could be found in any of the categories.

	Kris Maglione [:kmag]
	Comment 7 • 8 years ago

There are overlaps between several of those categories. I think that separating the add-ons into groups makes sense, but I'd rather the groups be something like:

- Temporarily installed
- User-installed
- Globally installed
- Built-in

	Andrew Swan [:aswan]
	Comment 8 • 8 years ago

I think the category list has collapsed a two-dimensional space into a flat list.
The two important dimensions are how the extension is written (webextension, sdk, overlay, etc) and how it is installed (temporary, system, regular).
Not all of the combinations exist and some can't ever exist (temporary overlay for instance) but I think it would make sense to track those attributes separately.  Let the bikeshedding on what to call them commence...

	Kris Maglione [:kmag]
	Comment 9 • 8 years ago

I'm not sure how much "how the extension is written" matters. If you're debugging an extension, chances are you already know how it's written. The main issue I have, and the reason I complained about this, is that when I open about:debugging, I get a list of add-ons I haven't heard of, and it's not obvious where they came from.

That's mainly an issue for system add-ons, which are hidden by default, and could easily be confused for malware. But it's also useful information for globally-installed add-ons. And having temporary add-ons grouped separately, at the top, is particularly handy, given they're probably the ones that you're most interested in.


If we want to expose information about how the add-on is written. Well. I suppose we could try. But there are too many hybrids. Any kind of extension can load SDK modules. Soon any kind of extension will be able to bundle a WebExtension. Bootstrapped v. overlay might be sort-of useful information, except that overlay add-ons aren't debuggable, and are also deprecated to the point that we shouldn't really even care about them.

But, anyway, that's a separate bug.

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

I agree with Kris that filtering out the System Addons by default and put the temporarily installed addon grouped at the top of the list would make enough to make the things way nicer.

	Andrew Swan [:aswan]
	Comment 11 • 8 years ago

(In reply to Kris Maglione [:kmag] from comment #9)
> I'm not sure how much "how the extension is written" matters.

I didn't mean to express judgement on how valuable it is, just to point out that the list from comment 3 included this information.  I agree that "how it is installed" is the single most useful thing to distinguish within about:debugging.

	Andy McKay
	Comment 12 • 7 years ago

Temporary add-ons are now show at the top.

System add-ons are grouped with all the other add-ons. Personally this works really well for me when developing, because I ignore the rest.

	Mark Striemer [:mstriemer] Assignee
	Comment 13 • 6 years ago

This was fixed in bug 1425347.