1423849 - devtools extensions cannot be hidden permanently

Status: RESOLVED DUPLICATE of bug 1394750

(DevTools :: General, defect, P2)

Description

[Julian Descottes [:jdescottes]]

STRs:
- install https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/
- open devtools (should see HTTPS everywhere extension)
- open devtools options panel
- disable HTTPS everywhere
- close and reopen devtools

AR: HTTPS Everywhere is back in the devtools toolbar
ER: HTTPS Everywhere still absent from devtools toolbar

Looking at the prefs being flipped by the checkbox, it looks like the extension gets a different ID everytime devtools start. Eg when I disable it once it flips devtools.webext-https-everywhere_eff_org-127-0-devtools-panel.enabled to false, but when I start devtools again, a new pref is created for the extension named devtools.webext-https-everywhere_eff_org-151-0-devtools-panel.enabled

This seems to happen for any devtools webextension, but it's particularly critical for webextensions that package an additional DevTools panel (https everywhere, adblock plus) because users might want to keep the extension without having the devtools panel. 

For webextensions that are purely a DevTools panel (such as axe developer tools), the user can remove/disable the extension to get rid of the panel.

Comment 1

[Julian Descottes [:jdescottes]]

Part of the issue seems to come from https://searchfox.org/mozilla-central/source/browser/components/extensions/ext-devtools-panels.js#465-467. newBasePanelId() always returns a different id for a given webextension (either the context id changes or the increment).

Two options based on that: 
- either we create unique and stable ids in newBasePanelId()
- devtools need to handle panels with such ids in a different manner

Luca: what do you think?

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

Like briefly discussed over IRC, I totally agree that the behavior of the checkbox in the developer toolbox preferences should be different from the one related to the integrated panels (e.g. the checkbox should be associated to the entire extension instead of a single panel, and when the user uncheck it, we should disable also the other "devtools pieces" of the related extension, so that the invisible devtools_page and the created inspector sidebar panels are also disabled when the checkbox is disabled).

I've described the behavior that I think would be more reasonable (and it would make that checkbox to work as described in comment 0) in Bug 1394750 Comment 9.

I'm resolving this bug as a duplicate of Bug 1394750 (and I'm going to add a new comment there with a more detailed plan of the needed changes).