456984 - "New Tab" Customizable Button Needs to Be Added Back

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect, P1)

Description

[John]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080925033548 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080925033548 Minefield/3.1b1pre

Because of Bug 455756, a the new tab button was added to the tab bar. However, some users do not display the tab bar by default when there is only one page open. As a result, there is no button to click on to create a new tab. We know about Control-T, but that's not the point. 

There is no option to add a new tab button to the other toolbars.



Reproducible: Always

Steps to Reproduce:
1. Right click and customize the toolbars.

Actual Results:  
The customizable new tab button is missing

Expected Results:  
The customizable new tab button should be available

This feature was around since before Firefox 1. The fact that it disappeared in less than a week is outrageous. It better have been a mistake and not intentional.

Comment 1

[u88484]

The tabbar is shown by default now.

Comment 2

[John]

But there's an option to hide it. Then there's no way to get a new tab button.

Comment 3

[Dão Gottwald [:dao]]

(In reply to comment #2)
> But there's an option to hide it.

Bug 455864 is going to degrade that to a hidden pref.

Comment 4

[John]

After reading Bug 455864, you might as well mark this as invalid, because if the option to hide the tab bar is made hidden and the button will not be added to customize other menus, the argument is over. 

It seems that Mozilla has some ideas for a better UI with the tab bar visible all times. I trust you guys in the long run, but this change was very quick and unexpected. I need to get used to it.

Comment 5

[Bryan]

I agree that the developers should restore the freedom users have had for years in being able to drag and drop toolbar buttons such as this back.  The fixed state of the new tab button isn't even user friendly!  At least Microsoft got that right and put it right next to the last tab!!!  Now I have to either Ctrl-T or drag my mouse all the way over to that fixed button, and believe me on a large wide screen it's now a pain.  It's small things like this that really drive users away.

~B

Comment 6

[John]

This is really bad for widescreen users. I have one. It's out of the way. And I can't see the immediate benefit of having the tab bar open all the time. I can;t get used to it.

Comment 7

[(mostly gone) XtC4UaLL [:xtc4uall]]

making the tab bar always visible by default is *no* reason to drop the new tab button in total, despite of what Bug 455864 says.

my user case:
i have set up my toolbar buttons like this:
http://img257.imageshack.us/img257/2254/bug456984ze5.png
with the change of Bug 455756 the "mouse way" of opening new tabs is way too far from locationbar *and* the other toolbar buttons where the other chrome actions happen (reload, stop, entering new url).
i wouldn't call this new behavior very efficient.

proposal:
- change of Bug 455756 is default
- make the new tab button available again in the customization panel
- if a users drags the button to *any* toolbar, hide the newly introduced button on the tabstrip (since i see no point to have them both in UI at the same time)

Comment 8

[Grey Hodge (jX)]

There isn't much reason the navbar button needed to go away. It wasn't on by default, but was a customization for users who preferred that method. I'm all in favor of that button on the tabbar for new users, it's been needed since somewhere around the day after we got a tab bar, and it's good to have. BUT, this isn't a situation where we need a pref for choosing a codepath here. This is a case where the old functionality was merely being duplicated in a new button in a more discoverable place. That doesn't mean that we have to kill the old button. It decreases a user's out of the box customization choices for no valid reason. It's not a physical object we only have one of and thus it can only be in once place.

Comment 9

[Martijn Wargers (dead)]

Attachment: patch

Comment 10

[Damian Shaw [Quan]]

I was just about to make 3 different bugs nominated for blocking out of this:

1) As stated in this bug, not all users will have tab bar set to visible and so it makes it impossible to see with 1 window.

2) It removes a customisable part of the UI and replaces it with a static one, users will be rightfully annoyed and frustrated with this!

3) It places an "open new tab" button right next to the "close last tab on the bar", which makes it painful for users, especially give a lot don't know about History > Undo Close Tab.

Is there development agreement on these issues or should I make spin-off bugs?

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #5)
> I agree that the developers should restore the freedom users have had for years
> in being able to drag and drop toolbar buttons such as this back.  The fixed
> state of the new tab button isn't even user friendly!  At least Microsoft got
> that right and put it right next to the last tab!!!  Now I have to either
> Ctrl-T or drag my mouse all the way over to that fixed button, and believe me
> on a large wide screen it's now a pain.  It's small things like this that
> really drive users away.

Oh, I don't know. You've been threatening to leave as long as I've been involved in the project and you're still around.

When Dao asked me if we should remove the existing new tab button, I said that I couldn't see why people would want two buttons and so gave him the nod to yank it. People here have made some convincing arguments for: 

 a) wanting it to be on the navbar instead of the tab strip
 b) wanting it to be on the left instead of the right of the tab strip
 c) wanting it to not be anywhere at all

I think that this bug, as expressed in the title and comment 0, won't properly address any of those points. The correct solution would be to make the new "new tab" button draggable, such that it can be placed at the left or right of the tab strip, on the nav bar, or removed entirely. The current default placement and location is correct. This either requires a bugmorph (reporter can decide to do that) or a spinoff bug.

Comment 12

[Tony Mechelynck [:tonymec]]

(In reply to comment #11)
[...]
> People here have made some convincing arguments for: 
> 
>  a) wanting it to be on the navbar instead of the tab strip
>  b) wanting it to be on the left instead of the right of the tab strip
>  c) wanting it to not be anywhere at all
> 
> I think that this bug, as expressed in the title and comment 0, won't properly
> address any of those points. The correct solution would be to make the new "new
> tab" button draggable, such that it can be placed at the left or right of the
> tab strip, on the nav bar, or removed entirely. The current default placement
> and location is correct. This either requires a bugmorph (reporter can decide
> to do that) or a spinoff bug.

Well, if the user can drag the button elsewhere, as desired by the current Summary and recommended by the above paragraph, then it is much less of a problem if you, or I, or the reporter, doesn't like the default placement. The above paragraph seems to point towards making the tab bar one more customizable toolbar, with the tabs themselves (probably as one widget, like the bookmarks on /their/ toolbar) occupying most of it. Then other buttons, such as for instance the "New Tab" button, could be placed on that "tab toolbar" or, at user's choice, dragged elsewhere, such as on some other toolbar, on the menubar, or even parked on the button palette.

Comment 13

[Damian Shaw [Quan]]

Bug 457187 as per Beltzner's comments. Please mark it as duplicate of this bug if this bug gets morphed

Comment 14

[John]

So how do I go about morphing it? Do I mark this a duplicate of Bug 457187, or should that be marked a duplicate of this (since the other bug technically will solve the issue being debated here)

Comment 15

[Martijn Wargers (dead)]

I don't think this bug should be morphed into a different bug.
I see that bug 457187 is now created that is about being able to drag the new tab button thing (which seems like a good idea to me).

Although, perhaps comment 0, which describes this bug is perhaps the same as bug 457187. In that case, you could call this bug a duplicate of that bug. Or else, if this is about adding an extra new tab button to the "Customize.." section, then it should presumably become wontfixed.

Comment 16

[Martijn Wargers (dead)]

Attachment: extension that adds back the New Tab button

Comment 18

[John A. Bilicki III]

All my clients have Firefox with the toolbar buttons clearly visible, large, and with text labels. They know exactly where to get everything. Now if the new tab button disappears I'm going to have several hundred disgruntled people calling me asking why their buttons disappeared.

Personally I use both GUI and the keyboard...whatever requires the least thinking so I can concentrate on the task at hand. Minimal thought, not minimal GUI: that is how good design works. Isn't there an extension for this morphed version of the button? Why aren't IMPORTANT bugs like 405461, 383349, 423014, and 295977 being fixed?

Now I have to move my mouse 1800 pixels to the right side of the screen instead of 200. Wasn't a customizable GUI the whole point of Firefox to begin with? We don't even have a Go button any more...I have to manually create and edit a file to display it. I click the go button dozens of times a day and bookmark a page once a month...so why would we add to this counter-intuitive design and statically move the new tab button (without any text label and no roll-over titles don't count for squat for normal users who do light computing) that absolutely has to be located at the far right of my 24 inch screen? This is all horrible design which is one of the major reasons why people are rejecting Vista in example.

My tab bar is always set to display as well as my clients. They nor should I be expected to pres CTRL+T, double click, or "get used to" clicking on a little green plus arrow for something of such great significance. That is the beauty of customizability: whatever is easiest works and helps keep you productive. A counter-intuitive design will aggravate people, start requiring extra thinking for what should be a thoughtless action on the user's account, and ultimately turn people away. Plus why would the new tab button be removed but we can still add the new window button? 

Also to the OP of the bug, please (like every other bug report I've EVER made here) please consider what other people may search for before posting a bug report. The button was missing at some point in the nightly builds. I recommend using the REACTION as the title and the request as part of the expected textarea. If people start doing this more there would be fewer duplicate bugs.

Comment 19

[Damian Shaw [Quan]]

John A. Bilicki III please see bug 457187 and also bug 347930 if both of these make 3.1 (and the former will have to if the latter does) then the Firefox GUI will be more customizable in regards to tabs and the new tab button, not less.

Comment 21

[Simon Bünzli]

Reopening per Alex's comment at <http://groups.google.com/group/mozilla.dev.apps.firefox/msg/afb2641b2f53752d>:

1. Re-add a New Tab button to the toolbar palette.
2. Hide the new button on the tab bar whenever that button has been manually added.

Bonus points for reverting the IDs so that people already having customized their toolbars to show that button won't notice any difference.

This shall be a stop-gap measure until bug 347930 is fixed.

A reminder to everybody not contributing code: Please don't comment here but rather answer to Alex's post in the newsgroup!

Comment 23

[Nochum Sossonko [:Natch]]

Why is this late-compat and late-l10n, IMO we should use the same labels and tooltips as the other button. Removing dependency on bug 347930 as that is the long-term solution which will obsolete this bug, hence this is not dependent on that fix.

Comment 24

[Nochum Sossonko [:Natch]]

Attachment: Hacky patch

This is a hacky patch to restore the old button and make the new button disappear when the old one is in use. This applies on top of the patch in bug 457651.

Comment 25

[Dão Gottwald [:dao]]

Comment on attachment 356892 [details] [diff] [review]
Hacky patch

Attribute names are usually lowercase.

#navigator-toolbox isn't in the scope of tabbrowser.css (see e.g. bug 404229 comment 6).

Comment 26

[Dão Gottwald [:dao]]

I think I'd call the attribute "hidenewtabbutton" (or something similar) and set it on gBrowser.

Comment 27

[Nochum Sossonko [:Natch]]

(In reply to comment #25)
> (From update of attachment 356892 [details] [diff] [review])
> Attribute names are usually lowercase.

Yeah, sorry about that, I'm just so used to that style...

> #navigator-toolbox isn't in the scope of tabbrowser.css (see e.g. bug 404229
> comment 6).

Can I put this in browser.css? I need to use #navigator-toolbox because it's reachable from the toolbox code, although I'll look into it later tonight. Also the attribute indicates whether the tab button is in the palette or not, in other words: true means it's *not* on the toolbar, rather in the palette.

Comment 28

[Dão Gottwald [:dao]]

We shouldn't touch customizeToolbar.js for this (unless a new generic hook is needed). BrowserToolboxCustomizeChange might be what you're looking for.

Comment 29

[Nochum Sossonko [:Natch]]

Comment on attachment 356892 [details] [diff] [review]
Hacky patch

Hrm, you're right I should probably just use BrowserToolboCustomizeDone, and it would be much easier to do it there. Although, can I put them in browser/content/browser.css instead of in each theme?

Comment 30

[Dão Gottwald [:dao]]

If you set the attribute on gBrowser, using tabbrowser.css should be fine.

Comment 31

[Shawn Wilsher :sdwilsh]

Natch - it looks like you are working on this, so I'm assigning it to you since this shows up as an unowned blocker currently.

Comment 32

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 2

Ok, this patch addresses the previous comments in a slightly different manner. What do you think of this approach? I decided to put the attribute on tabContainer because it's part of tabbrowser.xml and also enables more specific selectors instead of a general descendant selector.

Comment 33

[Nochum Sossonko [:Natch]]

Maybe the dynamic removal of the new buttons should be excluded from the patch, it messes a little bit with the tab scrolling. Nothing major, just some cosmetic stuff, if the right-most tab is fully visible, then switching to the old button leaves a small gap (the size of the new button) between the last tab and the right arrow, vice-versa as well. Not sure how to fix that, though. Thoughts?

Comment 34

[Ahmet Serkan Tıratacı]

I know nothing about coding Mozilla, but isn't it easier to undo the revision that took new tab button away to bring it back? Why does someone need to re-write it?

Comment 35

[Victor Bielawski]

(In reply to comment #34)
The actual functionality of the new tab button is kept from the previous patch. What needs to be written is the code to hide the button on the tab bar when the toolbar button is visible.

Comment 36

[Dão Gottwald [:dao]]

(In reply to comment #33)
> Maybe the dynamic removal of the new buttons should be excluded from the patch,
> it messes a little bit with the tab scrolling. Nothing major, just some
> cosmetic stuff, if the right-most tab is fully visible, then switching to the
> old button leaves a small gap (the size of the new button) between the last tab
> and the right arrow, vice-versa as well. Not sure how to fix that, though.
> Thoughts?

gBrowser.tabContainer.adjustTabstrip(), gBrowser.tabContainer._fillTrailingGap() and gBrowser.tabContainer._handleTabSelect() can be utilized.

Comment 37

[Dão Gottwald [:dao]]

Comment on attachment 357053 [details] [diff] [review]
Patch ver. 2

>@@ -3268,6 +3307,8 @@ function BrowserToolboxCustomizeDone(aTo
>         document.getElementById('Browser:Back').hasAttribute('disabled') &&
>         document.getElementById('Browser:Forward').hasAttribute('disabled');
> 
>+    var newTabButton = document.getElementById("new-tab-button");
>+    gBrowser.mTabContainer.setAttribute("hidenewtabbutton", newTabButton ? true : false);

any reason why this isn't in BrowserToolboxCustomizeChange?

Comment 38

[Nochum Sossonko [:Natch]]

I put it in BrowserToolboxCustomizeDone because it seems the rest of the ui is refreshed then, if you want it in BrowserToolboxCustomizeChange I can move it there. adjustTabstrip doesn't seem like it would do anything for me, and in my tests it hasn't really done much, although I should probably call it after the other methods to reset the [x] buttons. fillTrailingGap should work for the extra empty space, and I'll try the handleTabSelect, thanks.

Comment 39

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 3

This better? The ui is now perfect, no trailing gaps and no hidden tabs.

Comment 40

[Nochum Sossonko [:Natch]]

Attachment: for real now...

Sorry about that, patch got messed up somehow, thanks goes to bugzilla interdiff!

Comment 41

[Dão Gottwald [:dao]]

Comment on attachment 357284 [details] [diff] [review]
for real now...

>+//XXX Remove this post-3.1, used to show/hide the new tab button on the tab bar

Not really a useful comment, since we can't just remove it post-3.1.

>+function BrowserSetNewtabButton() {

Call this toggleTabstripNewTabButton, showHideTabstripNewTabButton or something like that.

>+  var newTabButton = document.getElementById("new-tab-button");
>+  if (newTabButton) {

if (document.getElementById("new-tab-button")) {

>+    gBrowser.mTabContainer.setAttribute("hidenewtabbutton", false);

Just remove the attribute, and use tabContainer rather than mTabContainer.

>+++ b/browser/base/content/tabbrowser.xml
@@ -127,6 +127,7 @@
>                     setfocus="false"
>                     onclick="this.parentNode.parentNode.parentNode.onTabClick(event);"
>                     xbl:inherits="onnewtab"
>+                    hidenewtabbutton="false"

that's unneeded

>+/* customizable new tab button */

"toolbar new tab button"?

>+/* customizable new tab button */

"tabstrip new tab button"?

Comment 42

[Dão Gottwald [:dao]]

(In reply to comment #41)
> >+/* customizable new tab button */
> 
> "tabstrip new tab button"?

This should refer to:

>+/* fixed new tab button */

Comment 43

[Nochum Sossonko [:Natch]]

Attachment: Adress Comments

Done.

Comment 44

[Dão Gottwald [:dao]]

(In reply to comment #38)
> I put it in BrowserToolboxCustomizeDone because it seems the rest of the ui is
> refreshed then, if you want it in BrowserToolboxCustomizeChange I can move it
> there.

Yes, please... There's no reason not to update the tab bar immediately when adding/removing the new tab button, as far as I can see.

You can also remove "XXX" from the comment in the latest patch, as it doesn't describe buggy behaviour.

Comment 45

[Nochum Sossonko [:Natch]]

Attachment: Patch ver. 3

Nits nixed!

Comment 46

[Dão Gottwald [:dao]]

Comment on attachment 357303 [details] [diff] [review]
Patch ver. 3

While you're at it, you might want to fix the curly brackets and indent the function bodies properly:

+var newTabButtonObserver = {
+  onDragOver: function(aEvent, aFlavour, aDragSession)
+    {
+      var statusTextFld = document.getElementById("statusbar-display");
...

Comment 47

[Nochum Sossonko [:Natch]]

The newWindowButtonObserver looks the same to me, although the other observers are somewhat different, should I change them all to be consistent? Or maybe you mean something else...

Seems like styling conventions in browser.js are somewhat inconsistent.

Comment 48

[Dão Gottwald [:dao]]

"var statusTextFld" is indented too far, and the curly bracket before it is on the wrong line. newWindowButtonObserver is indented oddly as well, but you shouldn't touch that here.

Comment 49

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 357303 [details] [diff] [review]
Patch ver. 3

Discussed this with beltzner and mconnor on IRC. Consensus was that the auto-hide behavior wasn't ideal, and that the ideal state for post-3.1 was to just fix bug 347930/bug 457187. That means for that for now (3.1), let's keep this bug simple and just restore the button as a customization option, letting users keep/add the old button in addition to the new one. That should also avoid the need to break string freeze.

Natch, do you want to patch that?

Comment 50

[Dão Gottwald [:dao]]

(In reply to comment #49)
> auto-hide behavior wasn't ideal, [...] That should also
> avoid the need to break string freeze.

Seems entirely unrelated.

Comment 51

[:Gavin Sharp [email: [e-mail]]]

Oops, yes, you're right. We'll have to add the strings back either way.

Comment 52

[Nochum Sossonko [:Natch]]

Attachment: bring it back

Alright, this should do it. :/

Comment 53

[Nochum Sossonko [:Natch]]

Attachment: bring it back -- indent fix

Sorry about that, I forgot to fix the indentation, same patch with the indentation fixed.

Comment 54

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 357524 [details] [diff] [review]
bring it back -- indent fix

Why do we need to bring the string back as opposed to doubling up from the other new tab button? I'm loathe to risk the l10n impact here ...

Comment 55

[:Gavin Sharp [email: [e-mail]]]

One of the strings is what appears in the status bar when you're dragging something over the new tab button - there is no suitable alternate for it already in the tree. The other is the same string as the existing new tab button, but would require us including tabbrowser.dtd in browser.xul if we wanted to use it.

We could probably live with just not having status bar hover text and adding the extra include if we really wanted to avoid making any l10n changes, but it looks like we're going to have to break string freeze for bug 380852 anyways, and the incremental cost of adding these two strings as well is low enough that it'd be worth doing here, I think.

Comment 56

[Axel Hecht [:Pike]]

I don't necessarily see bug 380852 breaking string freeze. I don't see me taking incremental arguments either, but rather see each string freeze break make a stand for its own.

Comment 57

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #55)
> One of the strings is what appears in the status bar when you're dragging
> something over the new tab button - there is no suitable alternate for it
> already in the tree. The other is the same string as the existing new tab
> button, but would require us including tabbrowser.dtd in browser.xul if we
> wanted to use it.

Can we get the patch in without string changes now (I'm even happy not having a tooltip for the button; honest) and file a follow-up to land the string changes after beta 3 but before rc1?

> the extra include if we really wanted to avoid making any l10n changes, but it
> looks like we're going to have to break string freeze for bug 380852 anyways,

I agree with Axel, fwiw, that bug 380852 isn't worth breaking string freeze pre-b3. That's another one we should and can take between b3 and rc1.

Comment 58

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 357524 [details] [diff] [review]
bring it back -- indent fix

This looks good, but is missing the gnomestripe theme changes. With those restored (reveral of the gnomestripe removals in attachment 340241 [details] [diff] [review] should do), r=me.

Comment 59

[:Gavin Sharp [email: [e-mail]]]

Also, we still need to sort out whether we can add the new strings as-is - we might have to use the workaround I suggested in comment 55.

Comment 60

[Nochum Sossonko [:Natch]]

Attachment: Version without strings

I don't know what the decision will be, but unless tabbrowser.dtd is added to the list of browser.xul's dtds we can't use the string from the other new tab button. So here's a version of the patch without the strings, I'll post one with the strings shortly.

Comment 61

[Nochum Sossonko [:Natch]]

Attachment: Version with the strings

Here's the one with the strings.

I put the stuff in gnomestripe.css back in both patches.

Comment 62

[Mike Beltzner [:beltzner, not reading bugmail]]

As per comment 57, I think we should review and land attachment 358306 [details] [diff] [review] (without strings) and then file a P2 blocker follow up to take the strings after b3 from attachment 358308 [details] [diff] [review].

Comment 63

[Ed Lee :Mardak]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/79896d61e23f

Still needs to land on trunk.

Comment 64

[Ed Lee :Mardak]

Attachment: 1.9.1 patch

There were some conflicts for 1.9.1 (USE_TAB_PREVIEWS stuff).

Comment 65

[Ed Lee :Mardak]

Not sure what the whiteboard [stop-gap for 3.1 only] means... but pushed to trunk with strings.

http://hg.mozilla.org/mozilla-central/rev/32d2492bf68c

Comment 66

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Extra long tab bar

Sorry, but is this the expected behavior? As how it is working right now, the new tab button inside the tab bar is shifted to the left. Means you will get an extremely long tab bar and you aren't able to open several new tabs at once because the button is shifted each time a new tab gets opened.

Comment 67

[Shawn Wilsher :sdwilsh]

(In reply to comment #66)
> Sorry, but is this the expected behavior? As how it is working right now, the
> new tab button inside the tab bar is shifted to the left. Means you will get an
> extremely long tab bar and you aren't able to open several new tabs at once
> because the button is shifted each time a new tab gets opened.
bug 475082

Comment 69

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Shawn! So I can verify this fix on trunk and 1.9.1 branch with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090123033224

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090124 Minefield/3.2a1pre ID:20090124020327

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) Ubiquity/0.1.5 ID:20090123031537

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre ID:20090123022451

Comment 70

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I've updated the following Litmus test to cover the existence of the "New Tab" button.

Comment 71

[Henrik Skupin [:whimboo][⌚️UTC+1]]

https://litmus.mozilla.org/show_test.cgi?id=6044