Closed Bug 1361081 Opened 7 years ago Closed 6 years ago

[devtools-addon] CustomizableUI relies on developer-button

Categories

(DevTools :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jdescottes, Assigned: jdescottes)

References

Details

One of the entry points for devtools is the Firefox menu which contains a "Developer" menu item.

This menu item is dynamically added by devtools-browser.js [1]. When devtools will be extracted as an addon, this menu item will no longer be in the menu by default.
However several tests are relying on this "developer-button" (see a changeset [2] where I manually updated the tests to no longer rely on developer-button). 

Depending on how we want the UI shim for devtools to behave, we might still create a menu item for devtools by default, that would lead to install the devtools addon. This menu item would then be replaced by the real developer-button when devtools start.

Blocking this bug on dt-addon-uishim meta bug.

[1] http://searchfox.org/mozilla-central/rev/3dc6ceb42746ab40f1441e1e659ffb8f62ae78e3/devtools/client/framework/devtools-browser.js#410-458

[2] https://hg.mozilla.org/try/rev/299cfe18122844010ee77b14add961e40651ef2f
Alex, since we are keeping the developer button, we don't actually *need* to update CustomizableUI.

But we could retrieve the button ID from the shim to clarify the dependency between CustomizableUI and DevTools. Seems reasonable to you?
Flags: needinfo?(poirot.alex)
(In reply to Julian Descottes [:jdescottes] from comment #1)
> Alex, since we are keeping the developer button, we don't actually *need* to
> update CustomizableUI.

I don't know if that can mess with the tests, but the shim button isn't going to include existing devtools menu (per tool entry for ex.).
If that's fine, then yes, sounds like there isn't much to do here.
But keep it open until we take the final decision on the UX.

> But we could retrieve the button ID from the shim to clarify the dependency
> between CustomizableUI and DevTools. Seems reasonable to you?

I'm not sure it is worth.
Flags: needinfo?(poirot.alex)
(In reply to Alexandre Poirot [:ochameau] from comment #2)
> (In reply to Julian Descottes [:jdescottes] from comment #1)
> > Alex, since we are keeping the developer button, we don't actually *need* to
> > update CustomizableUI.
> 
> I don't know if that can mess with the tests, but the shim button isn't
> going to include existing devtools menu (per tool entry for ex.).

From what I could see, the CustomizableUI only cares about the button, not the menu.

> If that's fine, then yes, sounds like there isn't much to do here.
> But keep it open until we take the final decision on the UX.

Sounds good to me.
The current situation is that the devtools menu items are only populated when we initialize devtools. 

When devtools will be an addon, even though the button will still be visible all the developer menus will be empty, and the developer-button will trigger the installation flow. We will need to update all the customizable-ui tests relying on devtools menu items:

- browser/components/customizableui/test/browser_981305_separator_insertion.js
- browser/components/customizableui/test/browser_989751_subviewbutton_class.js
- browser/components/customizableui/test/browser_overflow_use_subviews.js (clicks on the developer button to show a subview)
See Also: → 1387023
Product: Firefox → DevTools
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.