All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED FIXED in Firefox 35

Status

RESOLVED FIXED
4 years ago
4 months ago

People

(Reporter: pascalc, Assigned: vporof)

Tracking

unspecified
Firefox 36
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox35 fixed, firefox36 fixed)

Details

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

4 years ago
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

4 years ago
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.
Flags: needinfo?(shorlander)

Updated

4 years ago
Depends on: 1063206
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 ?
Flags: needinfo?(paul)

Comment 3

4 years ago
(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.
Flags: needinfo?(paul)
Created attachment 8509705 [details]
DevTools Toggles

Mockup using the devtools Wrench as a consistent metaphor for "Activate DevTools".
Flags: needinfo?(shorlander)

Comment 5

4 years ago
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!
Flags: needinfo?(shorlander)
(Assignee)

Updated

4 years ago
Assignee: nobody → vporof
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86_64 → All
(Assignee)

Comment 6

4 years ago
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?
Flags: needinfo?(paul)
Created attachment 8510593 [details]
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.
Flags: needinfo?(shorlander)
(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.
Flags: needinfo?(paul)
Flags: needinfo?(gijskruitbosch+bugs)

Comment 9

4 years ago
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?
Flags: needinfo?(gijskruitbosch+bugs)
(Assignee)

Comment 10

4 years ago
Created attachment 8510938 [details] [diff] [review]
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?
Attachment #8510546 - Attachment is obsolete: true
Attachment #8510938 - Flags: review?(gijskruitbosch+bugs)
Attachment #8510938 - Flags: feedback?(paul)
(Assignee)

Comment 11

4 years ago
Created attachment 8510939 [details]
Screen Shot 2014-10-24 at 5.26.53 AM.png

So this.

Comment 12

4 years ago
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.
Attachment #8510938 - Flags: review?(gijskruitbosch+bugs) → review+
(Assignee)

Comment 13

4 years ago
(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

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

Comment 15

4 years ago
(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?
(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 ?
(Assignee)

Comment 17

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

Touche :)
(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

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

Comment 21

4 years ago
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 :)
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.
(Assignee)

Comment 23

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

Comment 24

4 years ago
Created attachment 8512036 [details] [diff] [review]
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).
Attachment #8510938 - Attachment is obsolete: true
Attachment #8510938 - Flags: feedback?(paul)
Attachment #8512036 - Flags: review?(paul)
Since a dropdown isn't supported, you could try implementing my suggestion from comment 2.
(Assignee)

Comment 26

4 years ago
(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?
(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

4 years ago
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?
Flags: needinfo?(jgriffiths)

Comment 29

4 years ago
(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.
(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).
(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.
Flags: needinfo?(jgriffiths)
(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.
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

4 years ago
(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.
(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

4 years ago
(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).
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

4 years ago
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).
Attachment #8512036 - Flags: review?(paul) → review+

Comment 39

4 years ago
Created attachment 8514099 [details] [diff] [review]
v3

Here, I'm just replicating what we did for the WebIDE button (bug 1056923).
Attachment #8512036 - Attachment is obsolete: true
Attachment #8514099 - Flags: review?(gijskruitbosch+bugs)

Comment 40

4 years ago
We got sidetracked here. I will file a new bug for the original issue.
Summary: Provide an icon for the toolbar to activate/deactivate the devtools panel → make it possible to move the devtools button in the navbar by default

Comment 41

4 years ago
New bug: bug 1091462

Updated

4 years ago
Attachment #8512036 - Flags: review+

Comment 42

4 years ago
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.
Attachment #8514099 - Flags: review?(gijskruitbosch+bugs)

Comment 43

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

Updated

4 years ago
Assignee: vporof → nobody

Comment 45

4 years ago
(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.

Updated

4 years ago
Attachment #8512036 - Attachment is obsolete: false
Attachment #8512036 - Flags: review+
(Assignee)

Updated

4 years ago
Assignee: nobody → vporof
(Assignee)

Comment 47

4 years ago
Try was green.
Keywords: checkin-needed
Attachment #8512036 - Attachment is obsolete: true
Attachment #8512036 - Attachment is obsolete: false
Attachment #8514099 - Attachment is obsolete: true
https://hg.mozilla.org/integration/fx-team/rev/f3cc40b3abf2
Flags: in-testsuite+
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/f3cc40b3abf2
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 36
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
Attachment #8512036 - Flags: approval-mozilla-aurora?
(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 :)

Updated

4 years ago
Depends on: 1093507
Attachment #8512036 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/e762025b9358
status-firefox35: --- → fixed
status-firefox36: --- → fixed

Updated

4 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.