Closed
Bug 1067337
Opened 10 years ago
Closed 10 years ago
make it possible to move the devtools button in the navbar by default
Categories
(DevTools :: General, defect)
DevTools
General
Tracking
(firefox35 fixed, firefox36 fixed)
RESOLVED
FIXED
Firefox 36
People
(Reporter: pascalc, Assigned: vporof)
References
Details
Attachments
(4 files, 3 obsolete files)
380.08 KB,
image/png
|
Details | |
372.57 KB,
application/zip
|
Details | |
110.74 KB,
image/png
|
Details | |
34.35 KB,
patch
|
paul
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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•10 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)
Comment 2•10 years ago
|
||
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•10 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)
Updated•10 years ago
|
Blocks: fx-dev-edition
Comment 4•10 years ago
|
||
Mockup using the devtools Wrench as a consistent metaphor for "Activate DevTools".
Flags: needinfo?(shorlander)
Comment 5•10 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•10 years ago
|
Assignee: nobody → vporof
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86_64 → All
Assignee | ||
Comment 6•10 years ago
|
||
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)
Comment 7•10 years ago
|
||
(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)
Comment 8•10 years ago
|
||
(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)
Updated•10 years ago
|
Flags: needinfo?(gijskruitbosch+bugs)
Comment 9•10 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•10 years ago
|
||
(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•10 years ago
|
||
So this.
Comment 12•10 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•10 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•10 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•10 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?
Comment 16•10 years ago
|
||
(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•10 years ago
|
||
(In reply to Tim Nguyen [:ntim] from comment #16) > > The aurora one ? Touche :)
Comment 18•10 years ago
|
||
(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•10 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...
Comment 20•10 years ago
|
||
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•10 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 :)
Comment 22•10 years ago
|
||
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•10 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•10 years ago
|
||
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)
Comment 25•10 years ago
|
||
Since a dropdown isn't supported, you could try implementing my suggestion from comment 2.
Assignee | ||
Comment 26•10 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?
Comment 27•10 years ago
|
||
(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•10 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•10 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.
Comment 30•10 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? 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•10 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? I really really want the button to *just* open the toolbox. +1.
Flags: needinfo?(jgriffiths)
Comment 32•10 years ago
|
||
(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•10 years ago
|
||
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•10 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.
Comment 35•10 years ago
|
||
(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•10 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).
Comment 37•10 years ago
|
||
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•10 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•10 years ago
|
||
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•10 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•10 years ago
|
||
New bug: bug 1091462
Updated•10 years ago
|
Attachment #8512036 -
Flags: review+
Comment 42•10 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•10 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 | ||
Comment 44•10 years ago
|
||
(attachment 8512036 [details] [diff] [review])
Assignee | ||
Updated•10 years ago
|
Assignee: vporof → nobody
Comment 45•10 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•10 years ago
|
Attachment #8512036 -
Attachment is obsolete: false
Attachment #8512036 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → vporof
Assignee | ||
Comment 46•10 years ago
|
||
Try: https://tbpl.mozilla.org/?tree=Try&rev=8b1937512cf5
Updated•10 years ago
|
Attachment #8512036 -
Attachment is obsolete: true
Updated•10 years ago
|
Attachment #8512036 -
Attachment is obsolete: false
Updated•10 years ago
|
Attachment #8514099 -
Attachment is obsolete: true
Comment 49•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f3cc40b3abf2
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 36
Comment 50•10 years ago
|
||
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?
Comment 51•10 years ago
|
||
(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•10 years ago
|
Attachment #8512036 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 52•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/e762025b9358
status-firefox35:
--- → fixed
status-firefox36:
--- → fixed
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•