457187 - Make the tabs toolbar customizable

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, enhancement)

Description

[Damian Shaw [Quan]]

Steps to reproduce:

1. Go View > Toolbars > Customize 
2. Attempt to drag and drop the new 'new tab' button
3. Nothing happens

Expected Results:

Should at least be able to place each side of the tab bar or in the nav bar. Having static items all around Firefox make it awkward for the user.

Comment 1

[Tyler Downer [He/Him]]

Agree, but there is not much to move it around to.

Comment 2

[Damian Shaw [Quan]]

(In reply to comment #1)
> Agree, but there is not much to move it around to.

Well nothing says its size can't change per-bar like every other dragable button.

Comment 3

[Tyler Downer [He/Him]]

Yes, and I guess if you are like me, and just use Ctrl+T, or middle click, or even just double-click on the tab bar, the new tab button is just taking up space, so it would be nice to get rid of it if you wanted as well.

Comment 4

[Tony Mechelynck [:tonymec]]

Maybe change the tab bar to a customizable toolbar containing (by default and not necessarily in this order):
1) new tab button
2)- all tabs (one item, like "all personal bookmarks" are one item on their bar). Probably not removable, like the menus on the menubar.
3) all tabs menu

Maybe redefine browser.tabs.closeButtons and/or make the (4) close-tab button an "ordinary" customizable button.

This way 1,3,4 could be "removed" by dragging them to the buttons storage popup (and 4 would probably be parked on it by default).

Comment 5

[Gilberto Olimpio]

I agree with Tyler, the new tab button takes space. Probably it's good for the new users, but I'd like to have an option to remove it.

Comment 7

[Darren Hill]

A side note:
This new immovable 'new tab' widget is as far away from where people
enter urls or open bookmarks as possible.  This makes it difficult to use, in my opinion.
If I want to open a few tabs from my bookmarks I have to go all the way to the
right of the screen, back to the bookmarks menu, and then back all the way
across the screen.

I know I can double click on the 'tab area' where there isn't a tab but I don't think that's a well known feature.  It also runs into the same problem once you have more then a few tabs open.

Comment 8

[Zack]

Either make it moveable or bring back the old button. A very common move for me is to customize my toolbar and have the new tab button right next to the HOME button. I don't always, but very commonly use the NEW TAB followed by the HOME button. I don't want a new tab to always open my HOME page, but quite often I do. Now it's on the other side of the screen.

Again, please either make it moveable or give me the option of putting a TAB button where I want it. Please!

Comment 9

[Tyler Downer [He/Him]]

Zack, I think that it is agreed that the button needs to be movable.

Comment 10

[Michael Monreal [:micmon]]

I tried using the button in the new location but it totally breaks my workflow and I think it does for quite a few users. Please change it back or make it movable.

(adding myself to the cc)

Comment 11

[Tony Mechelynck [:tonymec]]

(In reply to comment #10)
> I tried using the button in the new location but it totally breaks my workflow
> and I think it does for quite a few users. Please change it back or make it
> movable.
> 
> (adding myself to the cc)

With the latest version (0.3.7, for Firefox 2.0 to 3.1b1pre) of Tab Mix Plus, published a few hours ago at AMO, you can get that button (among other locations) at the left end of the tab bar, even in Firefox 2. I haven't checked whether it retrofits a "new tab" toolbar button (as opposed to a tab bar button) to Fx3 but I think it isn't unthinkable.

Comment 12

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

Just to note it also applies to users who are switching back to Firefox 3.0.x. At least when you have started Firefox 3.1 once you won't be able to remove the button from the tabbar anymore with Firefox 3.0.

Comment 13

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

Please dismiss my last comment.

Comment 14

[siegfre]

(adding myself to cc list)

Comment 15

[Tyler Downer [He/Him]]

I think a better summary is customizable and an enhancement.

Comment 16

[Damian Shaw [Quan]]

Does it make logical sense for it to be both an enhancement and a regression?

Comment 17

[Tyler Downer [He/Him]]

I just noticed that, and no, it does not make sense. Since this feature just came out, and with an enhancement, not possible to be a regression.

Comment 18

[Damian Shaw [Quan]]

Well Reed is the one who marked it so, so I kind of just trust anyone with @mozilla.com at the end of their e-mail address XD

I guess it depends whether you consider the new tab button a 'new feature' or a 'modified feature'

Comment 19

[Michael Monreal [:micmon]]

For many users this is a serious regression as it totally changes the way you have to interact with the browser. Don't take this lightly.

Comment 20

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

(In reply to comment #17)
> I just noticed that, and no, it does not make sense. Since this feature just
> came out, and with an enhancement, not possible to be a regression.

That's not true. Please start Firefox 3.0.x and add the "new tab" button to any of your toolbars. Afterwards start Firefox 3.1. You will see that the button is gone and can't be moved to the place it was before. This was introduced by bug 455756. So it's definitely a regression.

Comment 21

[Reed Loden [:reed]]

(In reply to comment #18)
> Well Reed is the one who marked it so, so I kind of just trust anyone with
> @mozilla.com at the end of their e-mail address XD

Please note that not everything I do in Bugzilla is official business. I probably do more community/personal stuff in Bugzilla than I do work stuff. :)

Comment 22

[Tyler Downer [He/Him]]

First @Damian, this button in it's current configuration is a new feature (or an extremely modified existing feature). 

Micheal, I am taking this issue seriously, since I personally want the ability to remove this from the toolbar altogether if I want (which I do).

Henrik, this could potentially be called a regression, but this button did not exist in 3.0.x, in it's current state. It was an option, but not default. It is a new enhancement in the current status of this but, requesting that the ability to customize it be added. I don't see a request for the Awesome Bar being called a regression, do you? (except for the few who do not like it and so continue with 2.0.0.x)

Comment 23

[Damian Shaw [Quan]]

(In reply to comment #22)
> I don't see a request for the Awesome Bar
> being called a regression, do you? (except for the few who do not like it and
> so continue with 2.0.0.x)

I don't want to get in to too much bug spam, but the awesomebar has a quantitatively different purpose to the old address bar, it provides results by using an out of order search and then weighting the results with a frecency algorithm. The new new tab button has the exact same quantitative purpose as the old new tab button, to open a new tab, except now you can do less with it.

Whether you call it a regression or not, is somewhat a philosophical point I think (not too indifferent to Theseus's paradox). But calling a regression and asking it to block Firefox 3.1 on a greater level than 'enhancement' seems more likely to get something done.

A dev decision on this would be nice, is it even feasible to get the code written in time at this point?

Comment 24

[Tyler Downer [He/Him]]

(In reply to comment #23)
> A dev decision on this would be nice, is it even feasible to get the code
> written in time at this point?
Exactly, can we get a dev on this?

Comment 25

[Martijn Wargers (dead)]

(In reply to comment #23)
> A dev decision on this would be nice, is it even feasible to get the code
> written in time at this point?

Sure, Dao is writing a patch in bug 347930 at this very moment.

Comment 26

[Tyler Downer [He/Him]]

Then is this a dupe, or will it just be fixed by that patch?

Comment 27

[Martijn Wargers (dead)]

It's not a dupe. Afaik, bug 347930 will lay the ground work of being able to fix this bug.

Comment 28

[Tyler Downer [He/Him]]

Ok, then we will keep it as is for now.

Comment 29

[alex_mayorga]

FWIW this extension brings back the "New Tab" to "Customize..." http://www.tom-cat.com/mozilla/firefox/extensions-newtabbutton.html

Comment 30

[Damian Shaw [Quan]]

The patch in bug 347930 makes it more customizable than it was before :)

Comment 34

[al_9x]

(In reply to comment #30)
> The patch in bug 347930 makes it more customizable than it was before :)

From that discussion, it's starting to look like it might not make 3.1.

It's not necessary to rearchitect the tab bar to address this bug.  One option to control whether the button appears on the tab bar or the tool bar would suffice for now, if bug 347930 doesn't make it

Comment 36

[Ralf Vitasek]

agreed. i also want my "new tab" button back. i'm so used to have it left to the url-bar.
the new location (imo) is a massive usability loss.

in fact i want nothing but tabs in the tab bar, no close button, no "all tabs" button, nothing. the ability to middle click to close and wheel to scroll through a way too long list of tabs is absolutely fine for me.

Comment 38

[Chris Garcia]

^ I agree with the above sentiments, don't make me go back to 3.0.x because of this huge inconvenience :(

Comment 39

[Tony Mechelynck [:tonymec]]

(In reply to comment #38)
> ^ I agree with the above sentiments, don't make me go back to 3.0.x because of
> this huge inconvenience :(

The Tab Mix Plus extension https://addons.mozilla.org/en-US/firefox/addon/1122 already allows _some_ customization of the New Tab button even in current trunk nightlies: e.g., I use it to place the button at far left of the tab bar, which is where I prefer it.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081029 Minefield/3.1b2pre - Build ID: 20081029012848

Comment 40

[tester]

the tab button is to important to be at the end of the tabs bar because:
1. it's at the "end of the screen"
2. users use the 'New Tab' button a lot, so it need to be a big button

Comment 41

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

Not going to block on this, but it seems like the easiest thing to do here would be to change the ID of the new tab button that appears on the tabstrip so that people who've customized their toolbar palette can keep their big new tabbutton even though there's another one on the tabstrip itself.

Comment 42

[Tony Mechelynck [:tonymec]]

(In reply to comment #41)
> Not going to block on this, but it seems like the easiest thing to do here
> would be to change the ID of the new tab button that appears on the tabstrip so
> that people who've customized their toolbar palette can keep their big new
> tabbutton even though there's another one on the tabstrip itself.

Don't know if relevant, but I'll mention it just in case:
If and when, don't use something which can be caught by

.tabbrowser-tabs *|tab { ... }

which is what userChrome-example.css and/or http://www.mozilla.org/unix/customizing.html recommend as CSS selector for user styles applying to tabs.

Comment 44

[John A. Bilicki III]

The whole point of Firefox was to create a customizable browser based on Gecko.

This is a MASSIVE regression because not only is the current nightly build new tab button no longer customizable by not having drag and drop functionality it is an implementation of an extension...so instead of leaving extensions to extension writers and concentrating on more important and long standing bugs (52500, 78414, 95657, 211991, 264131, 286368, 383349, 405461, 423014, 427522 as a few examples) by merging extensions in to Firefox it creates a much greater amount of work to be completed before stable builds are released. Additionally once Firefox 3.5 automatically updates all my clients will then be missing their new tab icon with text label. The average consumer does *not* comprehend buttons without text labels or hover text descriptions. This will be yet another reason to no longer use Firefox for them should they decide they are too lazy to contact me for support and most of them will not. So before commenting that someone else should open a tab in a certain manner instead of the way they prefer take a moment to research why Firefox exists in the first place...especially those who are pushing for extensions to be merged thus creating so many bugs that never end up getting fixed.

Arguing against being able to customize Firefox and thus fixing this regression is no different then arguing that Firefox should be abandoned altogether in favor of only having work completed on SeaMonkey instead. Not only should this be fixed it should also be a block. Not doing so goes against one of the fundamental reasons for Firefox's existence.

Comment 45

[Tyler Downer [He/Him]]

@John, Mike (in comment #41) already said this would not be a block, and it is marked as a regression. These decisions such as 
>Not doing so goes against one of the
>fundamental reasons for Firefox's existence. 
and
>The whole point of Firefox was to create a customizable browser based on Gecko.
Even if they are true, are for the devs to make. (Also, there is no Firefox 3.5 yet, we are working on Firefox 3.1)
So please, as said in the Etiquette, no pointless comments. I would like to see this, but there are a few other bugs that need work before this can be properly implemented. Like Bug 347930 9which is turmoil right now). 
This bug is marked as wanted for Firefox 3.1, which means it is one the developers radar.

Comment 46

[Martijn Wargers (dead)]

Bug 347930 won't be fixed in Firefox3.1. Perhaps the same should be decided regarding this issue as was done for bug 465843?
Or perhaps just keep the New Tab button the satchel as well as in the tabbar?

Comment 47

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #46)
> Bug 347930 won't be fixed in Firefox3.1. Perhaps the same should be decided
> regarding this issue as was done for bug 465843?
> Or perhaps just keep the New Tab button the satchel as well as in the tabbar?

I guess this could be the best solution for now, as Mike proposed here:

(comment #41)
> Not going to block on this, but it seems like the easiest thing to do here
> would be to change the ID of the new tab button that appears on the tabstrip so
> that people who've customized their toolbar palette can keep their big new
> tabbutton even though there's another one on the tabstrip itself.

What I would really like to see could be an improved tab bar section on the Options Panel making possible to add or remove the new tab button, the close button and the list all tabs button together with the existing option to hide or unhide the tab bar if only one tab is open.

Comment 48

[Damian Shaw [Quan]]

(In reply to comment #47)
> What I would really like to see could be an improved tab bar section on the
> Options Panel making possible to add or remove the new tab button, the close
> button and the list all tabs button together with the existing option to hide
> or unhide the tab bar if only one tab is open.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

This is off topic. But bug 347930 allows you to do what you are mostly asking and you can already remove close tab buttons http://www.softosphere.com/remove-close-button-firefox-tabs/ Please make separate bugs or design proposals, this bug is for the specific issue of New Tab being customisable.

(In reply to comment #46)
> Bug 347930 won't be fixed in Firefox3.1. Perhaps the same should be decided
> regarding this issue as was done for bug 465843?
> Or perhaps just keep the New Tab button the satchel as well as in the tabbar?

Related, have you seen 457651 ?

Comment 49

[Aaron Sloman]

As I wrote in bug 457651 I have for a long time been using 'customize' to get a "new window" button and a "new tab" button together to the right of the "help" 
button, I have been using that layout, and find it very useful having them so
close together since their function is so similar (FOR THIS USER -- you may be
different).

Consequently I find it *extremely* annoying, on trying Minefield, to discover
that somebody has decided that my preference is WRONG, and not only put the
button in a different place but made it unmovable. It may be useful for novices to have a "new tab" button somewhere on the tab bar, but removing the option that previously existed and was used by people like me is just arbitrary dictatorship.

Like some other people I find space on the tab bar precious, because I often have lots of tabs open.

Comment 50

[Randy Wilson]

Adding myself to the cc. I only care that the old new tab button can be added back so that it can be placed onto any customizable toolbar. I don't mind the new tab button existing on the tab bar. I'm currently using the "New Tab" extension by Cat Thief (http://www.tom-cat.com/mozilla/firefox/extensions-newtabbutton.html) to get the old functionality back.

Comment 51

[Szabolcs Horvát]

Like others, I'd just like to have the good old new tab button on the toolbar.  I don't mind if there's another one on the tab bar.

I'd like to note that with the new tab button gone from the toolbar, it is no longer possible to drag an URL onto the new tab button (to open it in a new tab) when the tab bar is hidden.  And when the tab bar is shown, but is full of tabs, the area where URLs can be dragged is severely reduced (this affects usability).

Dragging URLs to the new tab button is a gesture I use very often (I'm talking about URLs that appear as text in the web page---not links).

Comment 53

[johnwellshardy]

I also think that the elimination of the "New Tab" button from the Tool Bar options was a big mistake. One good reason to bring it back is that it is at least four times larger than that puny new "New Tab" button that is on the tab bar. It is much easier to hit the old button with the mouse cursor because it is so much larger.

Also, the new button is waaaaay over there, away from all the other buttons. The menu bar is in the upper left area. The main tool bar buttons are in the upper left area. Why would anyone want to put a variation of the New Window button so far away, and so much smaller? Imagine putting the "Back" button at the left end of the tool bar and the "Forward" button at the right end. Brake pedal and gas pedal four feet apart. Makes no sense to me.

Comment 54

[u88484]

Comments 47 through Comment 53, how about reading the complete bug first...more important the top area with the whiteboard, dependent/blocking bugs and the flags.
If you would have read the whiteboard, you would have seen "[patch in bug 347930]".  No need to spam this bug any longer with me too comments.

Maybe someone else will actually read this comment.

[patch in bug 347930] look at that bug for the solution and no more need for me too comments and complaining.

Comment 55

[Randy Wilson]

Looks like bug 347930 is not going to make 3.1 (or at least, nobody's answering the question), so keep the me toos coming.

Comment 56

[u88484]

The me toos as in the form of voting. Not spamming by commenting in hope of getting your bugzilla account banned ;)

I'll even provide the link to vote for this bug.

https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=457187#vote_457187

Comment 57

[Damian Shaw [Quan]]

(In reply to comment #55)
> Looks like bug 347930 is not going to make 3.1 (or at least, nobody's answering
> the question), so keep the me toos coming.

Beltzner reckons the patch is too risky for 3.1, hopefully will make 3.2.

Comment 58

[Martijn Wargers (dead)]

(In reply to comment #57)
> (In reply to comment #55)
> > Looks like bug 347930 is not going to make 3.1 (or at least, nobody's answering
> > the question), so keep the me toos coming.
> 
> Beltzner reckons the patch is too risky for 3.1, hopefully will make 3.2.

Which is a shame, because it especially makes sense in this release. In the next release, the damage would be already done.

For the people that want to further discuss the 'New Tab' issue, you can/should do that in the dev.apps.firefox newsgroup/mailing list:
http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-apps-firefox
You could open a new topic about it or participate in one of the older threads about it.

Comment 59

[T3st3r]

I'm using "New Tab" button sometimes and while I like Ctrl+T shortcut I still prefer to have this button, in some cases I may prefer to use mouse rather than keyboard. And no, I do not need space cleanup on my toolbars or wherever else - all stuff already fits perfectly so I need forced cleanup not more than I need guillotine when I'm having headache.
 
What is the clue to release software quicker but with nasty and known defect which will make it's use harder? As for me, I will dissatisfied with such release (this WILL harm my web experience). And I really doubt anyone will be happy to discover such problem but surely some users will get angry and you're risking to lose them with such releases quality and bugs treatment, IMHO. Sorry if my comment does not sounds fair enough.

Comment 60

[Tyler Downer [He/Him]]

Thank you for your opinion. However, I think it is well established that this is a desired feature, and Comment 54 and comment 56 both said:
>No need to spam this bug any longer with me too comments.

and

>The me toos as in the form of voting. Not spamming by commenting in hope of
>getting your bugzilla account banned ;)

PLEASE read the comments on this bug and don't kep posting comments that simply annoy everyone.

Please also notice comment 58. 

Maybe if people will actually read this comment, we can stop getting so many pointless comments.

Comment 62

[Nochum Sossonko [:Natch]]

Would an interim patch be taken for 3.1? There's a patch sitting in bug 456984 (attachment 340488 [details] [diff] [review]) that brings back the old button while keeping the new one. That would satisfy the need to place the new tab button wherever you choose, even if that means there's two buttons with the same purpose. Later when bug 347930 is taken, this would obviously be removed.

Comment 65

[cris]

(In reply to comment #58)
> (In reply to comment #57)
> > (In reply to comment #55)
> > > Looks like bug 347930 is not going to make 3.1 (or at least, nobody's answering
> > > the question), so keep the me toos coming.
> > 
> > Beltzner reckons the patch is too risky for 3.1, hopefully will make 3.2.
> 
> Which is a shame, because it especially makes sense in this release. In the
> next release, the damage would be already done.
> 
> For the people that want to further discuss the 'New Tab' issue, you can/should
> do that in the dev.apps.firefox newsgroup/mailing list:
> http://www.mozilla.org/community/developer-forums.html
> https://lists.mozilla.org/listinfo/dev-apps-firefox
> You could open a new topic about it or participate in one of the older threads
> about it.
Just to voice my agreement with comment #58.

If you can get this two together, leave them all out. land this but not the other one. is stupid. basically you are hurting a potential mass user base.

I used mozilla for 8 years, and i don't want to threat anything, but these series of stupid decisions made by mozilla in recent months really calls me to rethink alot of things.

Comment 66

[Tyler Downer [He/Him]]

(In reply to comment #65)
How many times do we have to say (Comment #60 is the last), no more me toos. This is being worked on. This bug was already marked "-" for blocking, it is marked "?" for wanted. LEAVE IT!

Comment 67

[Martijn Wargers (dead)]

Cris, as mentioned in comment 58, please take the discussion to the dev.apps.firefox newsgroup/mailing list:
http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-apps-firefox
It is more likely you will get a response there. Although I have to say, it doesn't help if you are making threats about this or that. Just try to come up with good reasons of why you think the current situation is not a good one.

Comment 68

[cris]

Its essentially firefox's own fortune, I don't really need any help, mozilla just needs to be careful what kind of decision they are making, eventually, hurting users will cause backlash, plain and simple.

I won't bother with this issue anymore. I made my attempt as an 8 year old supporter. I will just leave it.

The reason for why I think this current situation is not a good one?

Simple, what if users disable tabbar when only one tab is open? they would have no button to click for a new tab. Is that not good enough a reason?

Comment 69

[Dorus Peelen]

Oh come on, it's a miracle you only lost faith in firefox ui design now, i didn't need the tabmixplus extension up to firefox 2 (been using it since 0.9), but after firefox 2, and that annoying close button on tabs, i had to install it to fix that, and some other usability mistakes.

Now no doubt, there will be extensions to fix this problem, don't worry about that. This bug is just about default behaviour (or at least about easily changing default behaviour), and apparently that's not considered a high priority, compared to shipping firefox 3.1. You can repeat the same arguments again (to fix the 'if users disable tabbar when only one tab is open' problem, they kinda decided to remove the 'disable tabbar when only one tab is open' function, 'if it's broken, shoot it'. That's the way the ui designers think these days. At least the always show tabbar function can still be turned off again.

Anyway, to make this comment a little less pointless, please consider voting for bug 347930, that's where the patch is. Even when that one is minused for 3.1 already, we can still push for it.

Let's be nice and produce a link for it:

https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=347930#vote_347930

Comment 70

[John A. Bilicki III]

"usability mistakes"

Two or more clicks to achieve what can be (or in this case has been) done in a single click is what I'd call a usability mistake.

The problem is that extensions are being implemented as features and features are regressing! I highly doubt I am the only person that saves the installers for old versions of software because too often newer isn't always better.

Another usability mistake: default features should appeal to the largest common crowd which are normal non-technical users. If you are a technical user and you disagree with a design aspect *you* know *how* to change the design, the common user does *not*. Therefor it is the technical user's responsibility to take ten seconds to change the preference instead of alienating the common user so they can be lazy when Firefox installs.

Furthermore whoever has been pushing extension feature/feature regression has really made a huge mess of this...this regression fix is dependent on bug 347930 which itself is dependent on bug 380960. Go ahead and take a look but long story short to annul the tab button regression we have to wait for an animation to be implemented! This is like saying you can't have your meal because there is no topping on the desert! Even worse adding more animation effects is simply further GUI suicide. IE does not animate during full screen toggle where Firefox does which makes user interaction with the page undeniably impossible forcing the user to wait for the animation to stop and furthermore slows down their system just to animate something for the sake of, what? This also is exceptionally aggravating because it forces the user to wait for something that has already loaded and is visually available but not visually focusable. So we are to hope that this major regression which depends on a bug that depends on a bug that will likely implement more obnoxious resource intensive absolutely pointless animations (no offense to Dão) for the sake of lazy technical users?

Oh and until Mozilla sets up a forum where we can subscribe only to notifications about the bugs and regressions that matter instead of literally everything the me too's are exceptionally likely to continue.

What I'd like to know is who are the people responsible for triggering this regression in the first place? I have nothing against implementing new features but this is no different then Microsoft changing their main portal from MSN to Live to whatever will be associated with Windows 7. Add with destroying or don't destroy to begin with.

Comment 71

[cris]

(In reply to comment #69)
> 
> 
> Anyway, to make this comment a little less pointless, please consider voting
> for bug 347930, that's where the patch is. Even when that one is minused for
> 3.1 already, we can still push for it.
> 
> Let's be nice and produce a link for it:
> 
> https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=347930#vote_347930

Exactly why? when everybody understand this bug is in associate with 347930, and in associate with the original change (remove new tab button)..... and Mozilla isn't doing anything?

Im all for adding new functions, you want to add a new tab button on the tab bar? great, better, put it on left side, much more useful than on the far right side.

But hey. Why not leave toolbar button alone? You have COPY, PASTE, CUT, NEW WINDOW, DOWNLOAD buttons there!!! 

Anyone thinks new tab button won't be at least more useful than those?

Comment 72

[Tyler Downer [He/Him]]

Comment #67  and above. This is not a forum, but a technical bug reporting database for developers. If you continue spamming this bug you could get your account removed. This bug has more than enough info, it is waiting for someone to create a patch. Your comments are not appreciated since this bug is on the developers radar. Giving more and more useless comments is not going to "push" this anymore.

Comment 73

[Martijn Wargers (dead)]

Bug 456984 is now reopened again, so hopefully that one will be fixed for Firefox 3.1.

Comment 75

[Marc Auslander]

To just make the thing go away, add to userChrome

/* remove the tab bar's new tab button */
.tabs-newtab-button {    /* as of 20080926033937 Minefield/3.1b1pre */
  display: none!important;
}

Comment 76

[Nochum Sossonko [:Natch]]

(In reply to comment #75)
You should probably use:

visibility: collapse !important;

Comment 77

[Dão Gottwald [:dao]]

(In reply to comment #75)
> To just make the thing go away, add to userChrome
> 
> /* remove the tab bar's new tab button */
> .tabs-newtab-button {    /* as of 20080926033937 Minefield/3.1b1pre */
>   display: none!important;
> }

(In reply to comment #76)
> You should probably use:
> 
> visibility: collapse !important;

Since the intention is to hide the buttons permanently, display:none is just fine.

Comment 78

[Marc Auslander]

remove new tab button is an add-on in the mozilla repository that does

display:none

so I'd think anyone who wants this should just install the add-on, rather than hacking themselves.

(and my apologies for using so much space in this bug for a forum type discussion.)

Comment 79

[Vasilis Vasaitis]

Adding another user's perspective here: If this change remains for the final version of Firefox 3.1, could the New Tab button at least be moved to the left of the Tab Bar? The top left of the browser window has traditionally been where most of the navigation-related controls have been, where I'm used to putting the New Tab button in the Navigation Bar, and where Mozilla/Seamonkey has traditionally placed the button (i.e. at the left side of the Tab Bar like I'm suggesting). So with 3.1b2 it's almost always the case that I'll instinctively move the mouse pointer towards the top left, pause in momentary confusion, and then move it to the top right to hit the button.

I don't really mind the size as others have complained, as I've always used small buttons on the toolbar anyway, so it makes no difference.

Comment 80

[Damian Shaw [Quan]]

(In reply to comment #79)
> Adding another user's perspective here: If this change remains for the final
> version of Firefox 3.1, could the New Tab button at least be moved to the left
> of the Tab Bar? 

See bug 457651 and in fact the old new tab button will be back, see bug 456984. Otherwise write a new bug.

Comment 83

[Aaron Davies]

an additional design comment: it strikes me as bad UI to have buttons move around in the window any more than absolutely necessary, and the "new tab" button is constantly moving as tabs are opened and closed. i'd much rather have it pinned left or right in the window (on the rare occasions when i want it at all--usually i'd rather just use ctrl-t/middle-click).

Comment 84

[Damian Shaw [Quan]]

(In reply to comment #83)
> an additional design comment: it strikes me as bad UI to have buttons move
> around in the window any more than absolutely necessary, and the "new tab"
> button is constantly moving as tabs are opened and closed. i'd much rather have
> it pinned left or right in the window (on the rare occasions when i want it at
> all--usually i'd rather just use ctrl-t/middle-click).

Please see Bug 457651 for discussion on that.

Comment 85

[Zac Hansen]

I don't care if it's movable (removable) or just an option to turn it off, but
I want to be able to get rid of it without having to edit css files by hand or
install extra extensions.

Comment 88

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

This is not going to happen for Firefox 3.6, and we should decide if we want to make the tabstrip/toolbar change for 3.7 or later.

Comment 91

[u88484]

Dao, so this bug is going to cover allowing "any" button to be placed on the tabbar toolbar, correct?  Even extension's buttons?

Comment 92

[Damian Shaw [Quan]]

(In reply to comment #91)
> Dao, so this bug is going to cover allowing "any" button to be placed on the
> tabbar toolbar, correct?  Even extension's buttons?

In the original set of "make the tabbar a toolbar" the tab bar just became another movable object, so the tabbar toolbar acted like all other toolbars and everything could be moved off or on it.

This would make the tabbar toolbar consistent with other toolbars so I can't imagine why this wouldn't be the desired behavior. However I don't know if it really falls under the scope of this bug, it depends what the fix for this bug ends up being...

Comment 93

[Damian Shaw [Quan]]

Correction: "the tabs just became another movable object"

Comment 95

[Dão Gottwald [:dao]]

Attachment: wip

Lacks styling on Win and Mac

Comment 96

[Markus Stange [:mstange]]

What will create the space between the new-tab button and the alltabs button in
non-overflow mode?
(I've only skimmed the patch very briefly.)

Comment 97

[Dão Gottwald [:dao]]

(In reply to comment #96)
> What will create the space between the new-tab button and the alltabs button in
> non-overflow mode?

The new-tab button is anonymous content in that case, just like today.

Comment 98

[Dão Gottwald [:dao]]

Attachment: patch v1

I didn't spend too much time on pinstripe, as the toolbar buttons are going to change there.

Comment 99

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

Can you explain the general idea behind the theme changes? And the customizeToolbar.js changes?

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>@@ -3350,16 +3350,18 @@ function BrowserToolboxCustomizeDone(aTo

>+  allTabs.readPref();

> function BrowserToolboxCustomizeChange() {

>+  allTabs.readPref();

Isn't doing this on BrowserToolboxCustomizeDone() redundant if you're doing it for each BrowserToolboxCustomizeChange()?

>diff --git a/browser/base/content/browser.xul b/browser/base/content/browser.xul

>     <toolbar id="TabsToolbar"
>              fullscreentoolbar="true"

>+             defaultset="tabbrowser-tabs,new-tab-button,alltabs-button,tabs-closebutton"

Why is tabs-closebutton in the defaultset?

>diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml

>-      <field name="mTabstripClosebutton">

>-      <field name="mAllTabsPopup">

These are both several times in MXR's copy of addons. Worth adding compat shims?

Comment 100

[Dão Gottwald [:dao]]

(In reply to comment #99)
> Can you explain the general idea behind the theme changes?

They mostly maintain the current styling of the toolbar buttons that aren't anonymous anymore, and they attempt to apply a similar styling when other items are dropped on the tab bar.

> And the customizeToolbar.js changes?

They allow dropping items before the tabstrip, which would otherwise consume the events.

> >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
> 
> >@@ -3350,16 +3350,18 @@ function BrowserToolboxCustomizeDone(aTo
> 
> >+  allTabs.readPref();
> 
> > function BrowserToolboxCustomizeChange() {
> 
> >+  allTabs.readPref();
> 
> Isn't doing this on BrowserToolboxCustomizeDone() redundant if you're doing it
> for each BrowserToolboxCustomizeChange()?

Probably true.

> >diff --git a/browser/base/content/browser.xul b/browser/base/content/browser.xul
> 
> >     <toolbar id="TabsToolbar"
> >              fullscreentoolbar="true"
> 
> >+             defaultset="tabbrowser-tabs,new-tab-button,alltabs-button,tabs-closebutton"
> 
> Why is tabs-closebutton in the defaultset?

It's not removable, i.e. always there, but hidden depending on browser.tabs.closeButtons.

> >diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml
> 
> >-      <field name="mTabstripClosebutton">
> 
> >-      <field name="mAllTabsPopup">
> 
> These are both several times in MXR's copy of addons. Worth adding compat
> shims?

Sure.

Comment 101

[Dão Gottwald [:dao]]

Attachment: patch v2

made the suggested changes (BrowserToolboxCustomizeDone, mTabstripClosebutton, mAllTabsPopup)

Comment 102

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

Comment on attachment 441639 [details] [diff] [review]
patch v2

I didn't review the theme changes carefully (but I did test Mac/Linux).

Comment 103

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/6271a260562b
http://hg.mozilla.org/mozilla-central/rev/75afa4976c59

Comment 104

[Dão Gottwald [:dao]]

Attachment: fix a11y test

Note that I landed this already to fix the failure on mozilla-central.

Comment 105

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 441855 [details] [diff] [review]
fix a11y test

Thanks for asking review.

Conditional r+ for this a11y test change but I want confirmation from Marco that the primary bug fix doesn't regress tab interaction via AT.

Comment 106

[alexander :surkov (:asurkov)]

Dão, could you describe shortly the UI changes of your patch?

Comment 107

[Dão Gottwald [:dao]]

The patch sets this defaultset for the tabs toolbar: tabbrowser-tabs,new-tab-button,alltabs-button,tabs-closebutton
All buttons were previously part of the tabs container. Not all of them are visible all the time but hidden depending on various things (as before).

Comment 108

[alexander :surkov (:asurkov)]

(In reply to comment #107)
> The patch sets this defaultset for the tabs toolbar:
> tabbrowser-tabs,new-tab-button,alltabs-button,tabs-closebutton
> All buttons were previously part of the tabs container.

Where are they now and then why was the a11y fix about alltabs button only? (per comment of a11y mochitest fix "the all-tabs button isn't a child of the the tab container anymore".)

Comment 109

[Marco Zehe (:MarcoZ)]

Comment on attachment 441855 [details] [diff] [review]
fix a11y test

I don't see any change in interactions with tabs. This "All Tabs" button was previously only accessible via mouse emulation anyway, not via the keyboard. If created dynamically, it will just reappear for ATs.

Comment 110

[Dão Gottwald [:dao]]

(In reply to comment #108)
> (In reply to comment #107)
> > The patch sets this defaultset for the tabs toolbar:
> > tabbrowser-tabs,new-tab-button,alltabs-button,tabs-closebutton
> > All buttons were previously part of the tabs container.
> 
> Where are they now

They are direct children of the tabs toolbar.

> and then why was the a11y fix about alltabs button only?
> (per comment of a11y mochitest fix "the all-tabs button isn't a child of the
> the tab container anymore".)

Because the other buttons happen to be hidden by default, so the test didn't see them anyway.

Comment 111

[u88484]

Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100428 Minefield/3.7a5pre 

Thanks Dao! Great work on fixing a long, long standing issue of not being able to customize our tabbar and also allowing extensions to easily get along now without all the xbl binding mess.

Comment 112

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

The right click context menu for any empty space in the tab toolbar shows the same options as if it were a tab that you had right-clicked. As such, the only way to get to the customize option is to either right-click on a different toolbar like the navbar or bookmark toolbar, or to right-click on an item in the tab toolbar (like the "new tab" or "all tabs" buttons).

Shouldn't the "Customize" option be added to the context menu if you right click in the empty space in the toolbar?

Comment 113

[Asa Dotzler [:asa]]

The "customize" context menu is already severely inconsistent. I think that needs to be rethought and a full solution designed before we worry about the places it doesn't work as one-offs. 

Is anyone else seeing a giant tab strip occasionally with the text and icon button for new tab (button, not tab-button) showing up at the far right? So far I don't know what's triggering it and it seems intermittent.

Comment 114

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to comment #113)
> Is anyone else seeing a giant tab strip occasionally with the text and icon
> button for new tab (button, not tab-button) showing up at the far right? So far
> I don't know what's triggering it and it seems intermittent.

I think if you have a lot of tabs open, the new tab button gets changed from tab-like to button-like.

From the Customize window, it is button-like. If you move it to the right of the All tabs button, it stays button-like no matter what.

Comment 115

[Damian Shaw [Quan]]

Why can't tabs be removed from tab toolbar?

This seems inconsistent... Bookmarks can be removed from bookmark toolbar, awesome bar can be removed from navigation bar.

Comment 116

[Nochum Sossonko [:Natch]]

In a one-tab window, dragging that tab down to the content area now reloads the page like it used to pre-3.5. Just saying. (I think it's this bug that did it...)

Comment 117

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #116)
> In a one-tab window, dragging that tab down to the content area now reloads the
> page like it used to pre-3.5. Just saying. (I think it's this bug that did
> it...)

Thats bug: https://bugzilla.mozilla.org/show_bug.cgi?id=560791

Comment 118

[u88484]

(In reply to comment #112)
> The right click context menu for any empty space in the tab toolbar shows the
> same options as if it were a tab that you had right-clicked. As such, the only
> way to get to the customize option is to either right-click on a different
> toolbar like the navbar or bookmark toolbar, or to right-click on an item in
> the tab toolbar (like the "new tab" or "all tabs" buttons).
> 
> Shouldn't the "Customize" option be added to the context menu if you right
> click in the empty space in the toolbar?

Bug 457187

Comment 119

[u88484]

(In reply to comment #118)
> Bug 457187
I meant bug 553390 for adding a customize option to the context menu.

Sorry for the spam.

Comment 120

[Dão Gottwald [:dao]]

(In reply to comment #113)
> Is anyone else seeing a giant tab strip occasionally with the text and icon
> button for new tab (button, not tab-button) showing up at the far right? So far
> I don't know what's triggering it and it seems intermittent.

This happens if you switch back to an older trunk build.

Comment 122

[Dietrich Ayala (:dietrich)]

Big customization win, blocking+.