[devtools-addon] CustomizableUI relies on developer-button

ASSIGNED
Assigned to

Status

()

Firefox
Developer Tools
P3
normal
ASSIGNED
a year ago
10 months ago

People

(Reporter: jdescottes, Assigned: jdescottes)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

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.
(Assignee)

Comment 4

10 months ago
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)
(Assignee)

Updated

10 months ago
See Also: → bug 1387023
You need to log in before you can comment on or make changes to this bug.