1067337 - make it possible to move the devtools button in the navbar by default

Status: RESOLVED FIXED

(DevTools :: General, defect)

Description

[Pascal Chevrel:pascalc]

AFAIK, There is no easy way to activate the devtools panel, you either use the keyboard (CTRL+SHIFT+I) or you go though the menus/submenus (click on hamburger menu, then on development icon then on devtools menu item).

I think those are fine defaults for end users to avoid them opening devtools and be confused, but for webdevs, there should be the possibility to add a toggle icon for the devtools in the main toolbar, just like Firebug and Web developer add-ons do.

Note that if I am testing on a tablet, the keyboard shortcut is also not an option.

Webdevs are also web users, so there should be an easy way to switch between surfing mode and devtools mode.

Comment 1

[Paul Rouget [:paul]]

Agreed. We probably want the same icon as bug 1063206. I'd be happy to write this patch as soon as we have an icon.

Comment 2

[Tim Nguyen :ntim]

I don't think a new toolbar icon is necessary for this. It might be nice if you could just middle-click the developer button to launch the devtools though. What do you think ?

Comment 3

[Paul Rouget [:paul]]

(In reply to Tim Nguyen [:ntim] from comment #2)
> I don't think a new toolbar icon is necessary for this. It might be nice if
> you could just middle-click the developer button to launch the devtools
> though. What do you think ?

We want to re-use the bookmark widget layout.

[tb] | [tm]

Where [tb] is a toggle toolbar icon, and [tm] and dropdown icon, like with the bookmark menu.

Comment 4

[Stephen Horlander [:shorlander]]

Attachment: DevTools Toggles

Mockup using the devtools Wrench as a consistent metaphor for "Activate DevTools".

Comment 5

[Paul Rouget [:paul]]

Stephen, can you update Toolbar.png and menuPanel.png with these icons? And also update browser/devtools/webide/themes/icons.png with the wrench? Thanks!

Comment 6

[Victor Porof [:vporof][:vp]]

Attachment: v1

This simply converts the current wrench button to a menu-like button that defaults inside the navbar. Clicking it opens the toolbox. Clicking on the dropdown arrow should show the menu popup.

However, I couldn't figure out yet how to properly create the popup, since there doesn't currently seem to be any other customizable widget that works this way. Furthermore, when inside the hamburger menu, the button should work like it does now, not have a dropmark.

Paul, who can I ask about those widgets?

Comment 7

[Stephen Horlander [:shorlander]]

Attachment: DevTools-and-DevTools-Panel-01.zip

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #5)
> Stephen, can you update Toolbar.png and menuPanel.png with these icons? And
> also update browser/devtools/webide/themes/icons.png with the wrench? Thanks!

Added/changed icons.

Comment 8

[Tim Nguyen :ntim]

(In reply to Victor Porof [:vporof][:vp] from comment #6)
> Created attachment 8510546 [details] [diff] [review]
> v1
> 
> This simply converts the current wrench button to a menu-like button that
> defaults inside the navbar. Clicking it opens the toolbox. Clicking on the
> dropdown arrow should show the menu popup.
> 
> However, I couldn't figure out yet how to properly create the popup, since
> there doesn't currently seem to be any other customizable widget that works
> this way. Furthermore, when inside the hamburger menu, the button should
> work like it does now, not have a dropmark.
> 
> Paul, who can I ask about those widgets?

Ask :Gijs.

Comment 9

[:Gijs (he/him)]

Ugh.

What you're asking for isn't currently supported. You'll need a bunch of CSS and hacks and so on to make it work (looking at the bookmarks menu button isn't a good example because it was hacked together even more hacky than necessary in this case, because it needed to support submenus and so forth). Also, type="menu-button" buttons are... messy, especially in the panel.

Why do you want to do this this way? Why not just have a separate button that just toggles the toolbox?

Comment 10

[Victor Porof [:vporof][:vp]]

Attachment: v2

(In reply to :Gijs Kruitbosch from comment #9)
> Ugh.
> 
> What you're asking for isn't currently supported. You'll need a bunch of CSS
> and hacks and so on to make it work (looking at the bookmarks menu button
> isn't a good example because it was hacked together even more hacky than
> necessary in this case, because it needed to support submenus and so forth).
> Also, type="menu-button" buttons are... messy, especially in the panel.
> 

Thought so :(

> Why do you want to do this this way? Why not just have a separate button
> that just toggles the toolbox?

We'd like to be able to access the developer menu as well (so all the tools, not just "open the toolbox"). Attached is a patch that just moves the developer menu's default location to the navbar. How about this?

Comment 11

[Victor Porof [:vporof][:vp]]

Attachment: Screen Shot 2014-10-24 at 5.26.53 AM.png

So this.

Comment 12

[:Gijs (he/him)]

Comment on attachment 8510938 [details] [diff] [review]
v2

0) codewise, this looks sane enough to me.
1) if you want this to affect people who've customized anything at all, you'll need to do more than just this (probably an nsBrowserGlue.js modification - please re-request review if you go this route)
2) this affects release and stuff, right? That doesn't seem right to me, ie, I don't think this button should be on the toolbar by default there. You should check with UX rather than me, though.
3) I'm afraid this will break tests, you should trypush if you haven't already.

Comment 13

[Victor Porof [:vporof][:vp]]

(In reply to :Gijs Kruitbosch from comment #12)
> Comment on attachment 8510938 [details] [diff] [review]
> v2
> 
> 0) codewise, this looks sane enough to me.

Cool, that's all I wanted.

> 1) if you want this to affect people who've customized anything at all,
> you'll need to do more than just this (probably an nsBrowserGlue.js
> modification - please re-request review if you go this route)

Probably not, because this targets the developer edition, so probably a new profile? Anyway, this might mean some build-time preprocessing or prefs. I'll ask around what the desired behavior should be.

> 2) this affects release and stuff, right? That doesn't seem right to me, ie,
> I don't think this button should be on the toolbar by default there. You
> should check with UX rather than me, though.

See above.

> 3) I'm afraid this will break tests, you should trypush if you haven't
> already.

Thought so.

Comment 14

[Paul Rouget [:paul]]

(In reply to Victor Porof [:vporof][:vp] from comment #13)
> > 1) if you want this to affect people who've customized anything at all,
> > you'll need to do more than just this (probably an nsBrowserGlue.js
> > modification - please re-request review if you go this route)
> 
> Probably not, because this targets the developer edition, so probably a new
> profile? Anyway, this might mean some build-time preprocessing or prefs.
> I'll ask around what the desired behavior should be.

In vanilla Firefox, this widget should replace the existing wrench button, and not be in the navigation bar by default.

In devtools edition, it needs to be in the navigation bar by default.

Comment 15

[Victor Porof [:vporof][:vp]]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #14)
> (In reply to Victor Porof [:vporof][:vp] from comment #13)
> 
> In vanilla Firefox, this widget should replace the existing wrench button,
> and not be in the navigation bar by default.
> 
> In devtools edition, it needs to be in the navigation bar by default.

Is there a build-time preprocessor pragma for determining whether or not we're in the devtools edition or not?

Comment 16

[Tim Nguyen :ntim]

(In reply to Victor Porof [:vporof][:vp] from comment #15)
> (In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from
> comment #14)
> > (In reply to Victor Porof [:vporof][:vp] from comment #13)
> > 
> > In vanilla Firefox, this widget should replace the existing wrench button,
> > and not be in the navigation bar by default.
> > 
> > In devtools edition, it needs to be in the navigation bar by default.
> 
> Is there a build-time preprocessor pragma for determining whether or not
> we're in the devtools edition or not?

The aurora one ?

Comment 17

[Victor Porof [:vporof][:vp]]

(In reply to Tim Nguyen [:ntim] from comment #16)
> 
> The aurora one ?

Touche :)

Comment 18

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Victor Porof [:vporof][:vp] from comment #15)
> Is there a build-time preprocessor pragma for determining whether or not
> we're in the devtools edition or not?

#ifdef MOZ_DEV_EDITION

Comment 19

[:Gijs (he/him)]

(In reply to Panos Astithas [:past] (overloaded, please needinfo) from comment #18)
> (In reply to Victor Porof [:vporof][:vp] from comment #15)
> > Is there a build-time preprocessor pragma for determining whether or not
> > we're in the devtools edition or not?
> 
> #ifdef MOZ_DEV_EDITION

So then all these changes would be #ifdef'd? That's going to be interesting for the test fixes, if any are necessary...

Comment 20

[Panos Astithas (he/him) [:past] (please ni?)]

I should clarify that I just replied to the question without looking at the bug to get more context. In general we want to use prefs for every feature if possible and just enable them in dev-edition using the pragma in firefox.js.

Comment 21

[Victor Porof [:vporof][:vp]]

I think it'd be very hard to actually use prefs for this. #ifdefs are better suited for this bug, and yes, test changes are going to be fun :)

Comment 22

[Joe Walker [:jwalker]]

The first run experience wants an ID to highlight so people know what the toolbox button is for. Currently that's #developer-button. Could we make sure it stays that way? See bug 1063057 for details.

Comment 23

[Victor Porof [:vporof][:vp]]

(In reply to Joe Walker [:jwalker] (overloaded - needinfo me or ping on irc) from comment #22)

Yes, I won't change the button's id.

Comment 24

[Victor Porof [:vporof][:vp]]

Attachment: v2

Paul, see comment 9. Having a dropdown isn't supported, so I just moved the default placement of the button to the navbar. This gives you the dropdown and a quick way to open the toolbox (since the "toggle tools" menu item is the first one in the popup).

Comment 25

[Tim Nguyen :ntim]

Since a dropdown isn't supported, you could try implementing my suggestion from comment 2.

Comment 26

[Victor Porof [:vporof][:vp]]

(In reply to Tim Nguyen [:ntim] from comment #25)
> Since a dropdown isn't supported, you could try implementing my suggestion
> from comment 2.

I would never have guessed that middle-clicking does anything. I don't believe this is a common UX pattern, is it?

Comment 27

[Tim Nguyen :ntim]

(In reply to Victor Porof [:vporof][:vp] from comment #26)
> (In reply to Tim Nguyen [:ntim] from comment #25)
> > Since a dropdown isn't supported, you could try implementing my suggestion
> > from comment 2.
> 
> I would never have guessed that middle-clicking does anything. I don't
> believe this is a common UX pattern, is it?

Nope, it's not really noticeable. An alternative solution would be adding a new widget that just toggles the devtools, and change the icon of the existing one.

Comment 28

[Paul Rouget [:paul]]

Just a suggestion (but I will still look at this patch): the wrench icon could just open the toolbox. 

There's always the [Tools] menu to reach tools not reachable via the toolbox.

Here is a list of things that can't be reached from the toolbox:
- WebIDE
- browser toolbox / console
- connection screen
- scratchpad
- page source
- work offline
- Dev Toolbar

WebIDE will soon have its own button.
Browser toolbox and console are not tool used by normal users.
Connection screen is now useless with WebIDE.

That leaves us with:
- scratchpad
- page source
- work offline
- dev toolbar

Being able to reach these 4 features only via the [Tools] menu (or via a shortcut) doesn't sound bad compared to the benefit of being able to open the toolbox in one click.

Jeff, what do you think?

Comment 29

[:Gijs (he/him)]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #28)
> Just a suggestion (but I will still look at this patch): the wrench icon
> could just open the toolbox. 
> 
> There's always the [Tools] menu to reach tools not reachable via the toolbox.
> 
> Here is a list of things that can't be reached from the toolbox:
> - WebIDE
> - browser toolbox / console
> - connection screen
> - scratchpad
> - page source
> - work offline
> - Dev Toolbar
> 
> WebIDE will soon have its own button.
> Browser toolbox and console are not tool used by normal users.
> Connection screen is now useless with WebIDE.
> 
> That leaves us with:
> - scratchpad
> - page source
> - work offline
> - dev toolbar
> 
> Being able to reach these 4 features only via the [Tools] menu (or via a
> shortcut) doesn't sound bad compared to the benefit of being able to open
> the toolbox in one click.
> 
> Jeff, what do you think?

The menu panel and the default widgets ought to be enough to replace all the features of the old menubar. This is why work offline is in there in the first place.

More generally, I don't think removing the dropdown entirely is a good idea, but you really should get a ux-review if that's what you want to do.

Comment 30

[Tim Nguyen :ntim]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #28)
> Just a suggestion (but I will still look at this patch): the wrench icon
> could just open the toolbox. 
> 
> There's always the [Tools] menu to reach tools not reachable via the toolbox.
> 
> Here is a list of things that can't be reached from the toolbox:
> - WebIDE
> - browser toolbox / console
> - connection screen
> - scratchpad
> - page source
> - work offline
> - Dev Toolbar
> 
> WebIDE will soon have its own button.
> Browser toolbox and console are not tool used by normal users.
> Connection screen is now useless with WebIDE.
> 
> That leaves us with:
> - scratchpad
> - page source
> - work offline
> - dev toolbar
> 
> Being able to reach these 4 features only via the [Tools] menu (or via a
> shortcut) doesn't sound bad compared to the benefit of being able to open
> the toolbox in one click.
> 
> Jeff, what do you think?
I use the developer panel quite often to reach the devtools, so I wouldn't want it to go away.

Also note that Windows users don't have the menubar by default, so reaching those items would be much harder for Windows users. Especially if they don't know all the shortcuts.

Another reason not to remove it, is that it doesn't help discoverability  of new developer tools (or even current ones).

Comment 31

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #28)
> Just a suggestion (but I will still look at this patch): the wrench icon
> could just open the toolbox. 
> 
> There's always the [Tools] menu to reach tools not reachable via the toolbox.
> 
> Here is a list of things that can't be reached from the toolbox:
> - WebIDE
> - browser toolbox / console
> - connection screen
> - scratchpad
> - page source
> - work offline
> - Dev Toolbar
> 
> WebIDE will soon have its own button.
> Browser toolbox and console are not tool used by normal users.
> Connection screen is now useless with WebIDE.
> 
> That leaves us with:
> - scratchpad
> - page source
> - work offline
> - dev toolbar
> 
> Being able to reach these 4 features only via the [Tools] menu (or via a
> shortcut) doesn't sound bad compared to the benefit of being able to open
> the toolbox in one click.
> 
> Jeff, what do you think?

I really really want the button to *just* open the toolbox. +1.

Comment 32

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to :Gijs Kruitbosch from comment #29)
...
> More generally, I don't think removing the dropdown entirely is a good idea,
> but you really should get a ux-review if that's what you want to do.

From a product point of view, I really would rather we have just a simple button that opens the toolbox. We have some indirect data that hints at this user need as being the reason the developer toolbar is really popular - because the developer toolbar has a button that opens the toolbox. The easier we can make this the better, and in particular mouse-drive users ( designer-developers, we theorize ) are more likely to discover the tools.

Comment 33

[Tim Nguyen :ntim]

Note that I use the Browser Toolbox and Console quite often to debug add-on issues, or simply browser issues. And as far as I know these are not reachable via the toolbox. I also sometimes get to use the eyedropper without having the toolbox open. One other thing is that Firefox has Windows users, they don't have a menu bar shown by default. So for discovering, or simply accessing some devtools that are not available via the toolbox by default (scratchpad, eyedropper, dev toolbar), this is much harder.
Another note, as Gijs said, the Panel menu is supposed to be a replacement for the menu bar.

Comment 34

[:Gijs (he/him)]

(In reply to Jeff Griffiths (:canuckistani) from comment #32)
> (In reply to :Gijs Kruitbosch from comment #29)
> ...
> > More generally, I don't think removing the dropdown entirely is a good idea,
> > but you really should get a ux-review if that's what you want to do.
> 
> From a product point of view, I really would rather we have just a simple
> button that opens the toolbox. We have some indirect data that hints at this
> user need as being the reason the developer toolbar is really popular -
> because the developer toolbar has a button that opens the toolbox. The
> easier we can make this the better, and in particular mouse-drive users (
> designer-developers, we theorize ) are more likely to discover the tools.

I don't understand what discovery has to do with this. How does a button with a list of things have worse discovery characteristics than the same button with a bunch of items which allow you to do the same, but now give a text description of the tools that are available?

The only argument here seems to be "we care more about giving people easy access to a button that toggles the tools, than we care about having all the tools accessible via the toolbar/panel."

This breaks a significant number of workflows (as per previous comments). As far as I can tell, the change you're proposing will not just affect the developer edition, nor will it come with a pref to revert or any other "recourse". While you might ease discovery with your proposed solution, if I want scratchpad, the browser toolbox, browser console, to work offline, or view source, I'm going to be forced to use the traditional menu - or learn and use shortcuts for where they're available (even if I'm a mouse user). Especially on Windows and Linux, that's a significant step because the menu is not available by default.

Please, please get a ux-review before going ahead with such a change. I recognize that I am biased, but it seems to me that removing visible access to a whole bunch of features is too big a loss to justify the gain of a simple toggle button because people prefer clicking once over clicking twice.

Comment 35

[Tim Nguyen :ntim]

(In reply to :Gijs Kruitbosch from comment #34)
> (In reply to Jeff Griffiths (:canuckistani) from comment #32)
> > (In reply to :Gijs Kruitbosch from comment #29)
> > ...
> > > More generally, I don't think removing the dropdown entirely is a good idea,
> > > but you really should get a ux-review if that's what you want to do.
> > 
> > From a product point of view, I really would rather we have just a simple
> > button that opens the toolbox. We have some indirect data that hints at this
> > user need as being the reason the developer toolbar is really popular -
> > because the developer toolbar has a button that opens the toolbox. The
> > easier we can make this the better, and in particular mouse-drive users (
> > designer-developers, we theorize ) are more likely to discover the tools.
> 
> I don't understand what discovery has to do with this. How does a button
> with a list of things have worse discovery characteristics than the same
> button with a bunch of items which allow you to do the same, but now give a
> text description of the tools that are available?
I'm saying keeping the panel is better for discovery. Since many people don't know about the Scratchpad, the eyedropper or the dev toolbar for example. Having to find those items in the menu bar does not help for discoverability.

Comment 36

[Paul Rouget [:paul]]

(In reply to :Gijs Kruitbosch from comment #34)
> Please, please get a ux-review before going ahead with such a change.

Yes. We won't implement this without having ux, devtools and product on-board.

I will look at Victor's patch and see with him and Joe what we should do for now (short term / devedition).

Comment 37

[Joe Walker [:jwalker]]

If we have 2 buttons, one that opens the toolbox and the other that shows a menu, then we're OK for now, right?
Later we can join them into a single control.

Comment 38

[Paul Rouget [:paul]]

Comment on attachment 8512036 [details] [diff] [review]
v2

We used a pref for a similar feature (webide button) and not a preprocessing instruction.

Let's use a pref.

Victor, if you don't mind, I'll take care of this (I just did a similar thing with webide).

Comment 39

[Paul Rouget [:paul]]

Attachment: v3

Here, I'm just replicating what we did for the WebIDE button (bug 1056923).

Comment 40

[Paul Rouget [:paul]]

We got sidetracked here. I will file a new bug for the original issue.

Comment 41

[Paul Rouget [:paul]]

New bug: bug 1091462

Comment 42

[:Gijs (he/him)]

Comment on attachment 8514099 [details] [diff] [review]
v3

This is too simplistic considering it's an existing button. You're not removing it from the panel placements, and you've not updated the browser.xul code, nor the tests in case we actually end up enabling this by default in the devedition builds (which I presume is the plan).

Please have a look at victor porof's patch in the other bug.

Comment 43

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #42)
> Please have a look at victor porof's patch in the other bug.

Err, this bug, rather. Thought this was bug 1091462.

Comment 44

[Victor Porof [:vporof][:vp]]

(attachment 8512036 [details] [diff] [review])

Comment 45

[Paul Rouget [:paul]]

(In reply to :Gijs Kruitbosch from comment #42)
> Comment on attachment 8514099 [details] [diff] [review]
> v3
> 
> This is too simplistic considering it's an existing button. You're not
> removing it from the panel placements, and you've not updated the
> browser.xul code, nor the tests in case we actually end up enabling this by
> default in the devedition builds (which I presume is the plan).
> 
> Please have a look at victor porof's patch in the other bug.

Alright. Let's go for Victor's patch then.

Comment 46

[Victor Porof [:vporof][:vp]]

Try: https://tbpl.mozilla.org/?tree=Try&rev=8b1937512cf5

Comment 47

[Victor Porof [:vporof][:vp]]

Try was green.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/f3cc40b3abf2

Comment 49

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f3cc40b3abf2

Comment 50

[Joe Walker [:jwalker]]

Comment on attachment 8512036 [details] [diff] [review]
v2

Approval Request Comment
[Feature/regressing bug #]: New feature to allow the devtools button to be in the navbar by default
[User impact if declined]: DevEdition won't 
[Describe test coverage new/current, TBPL]: gum, fx-team, m-c
[Risks and why]: Some risk to navbar code, but this is well tested
[String/UUID change made/needed]: none

Comment 51

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Victor Porof [:vporof][:vp] from comment #21)
> I think it'd be very hard to actually use prefs for this. #ifdefs are better
> suited for this bug, and yes, test changes are going to be fun :)

Bug 1093507 is clear proof that they are fun indeed :)

Comment 52

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e762025b9358

Comment 53

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6994889d019e