Closed Bug 457187 Opened 16 years ago Closed 14 years ago

Make the tabs toolbar customizable

Categories

(Firefox :: Toolbars and Customization, enhancement)

Product:
Firefox
Component:
Toolbars and Customization
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.7a5
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: zurtex, Assigned: dao)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(2 files, 2 obsolete files)

patch v2
46.82 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
fix a11y test
593 bytes, patch
davidb
: review+
MarcoZ
: feedback+
Details | Diff | Splinter Review 
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.
Flags: wanted-firefox3.1?
OS: Windows Server 2003 → All
Hardware: PC → All
Agree, but there is not much to move it around to.
(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.
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.
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).
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.
Depends on: 455756
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.
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!
Zack, I think that it is agreed that the button needs to be movable.
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)
(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.
Flags: blocking-firefox3.1?
Keywords: regression
Blocks: 455756
No longer depends on: 455756
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.
Please dismiss my last comment.
(adding myself to cc list)
Depends on: 347930
I think a better summary is customizable and an enhancement.
Severity: normal → enhancement
Summary: 'New Tab' button should be dragable → 'New Tab' button should be customizable
Does it make logical sense for it to be both an enhancement and a regression?
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.
Keywords: regression
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'
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.
(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.
Severity: enhancement → normal
Keywords: regression
(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. :)
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)
(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?
(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?
(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.
Then is this a dupe, or will it just be fixed by that patch?
It's not a dupe. Afaik, bug 347930 will lay the ground work of being able to fix this bug.
Ok, then we will keep it as is for now.
FWIW this extension brings back the "New Tab" to "Customize..." http://www.tom-cat.com/mozilla/firefox/extensions-newtabbutton.html
The patch in bug 347930 makes it more customizable than it was before :)
Whiteboard: [patch in bug 347930]
(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
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.
^ I agree with the above sentiments, don't make me go back to 3.0.x because of this huge inconvenience :(
(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
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
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.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
(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.
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.
@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.
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?
(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.
(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 ?
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.
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.
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).
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.
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.
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.
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
(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.
(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.
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.
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.
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.
(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.
Flags: blocking-firefox3.1- → blocking-firefox3.1?
(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!
Flags: blocking-firefox3.1?
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.
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?
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
"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.
(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 #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.
Bug 456984 is now reopened again, so hopefully that one will be fixed for Firefox 3.1.
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 #75)
You should probably use:

visibility: collapse !important;
(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.
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.)
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.
(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.
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).
(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.
Flags: wanted-firefox3.6?
Flags: wanted-firefox3.5?
Flags: blocking-firefox3.6?
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.
Flags: wanted1.9.1.x?
Flags: wanted1.9.1.x?
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.
blocking2.0: --- → ?
Flags: wanted-firefox3.6?
Flags: wanted-firefox3.6-
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
Whiteboard: [patch in bug 347930]
Dao, so this bug is going to cover allowing "any" button to be placed on the tabbar toolbar, correct?  Even extension's buttons?
(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...
Correction: "the tabs just became another movable object"
Attached patch wip (obsolete) — — Splinter Review 
Lacks styling on Win and Mac
Assignee: nobody → dao
Status: NEW → ASSIGNED
Depends on: 549061
Severity: normal → enhancement
Keywords: regression
Summary: 'New Tab' button should be customizable → Make the tabs toolbar customizable
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.)
(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.
Attached patch patch v1 (obsolete) — — Splinter Review 
I didn't spend too much time on pinstripe, as the toolbar buttons are going to change there.
Attachment #439235 - Attachment is obsolete: true
Attachment #440238 - Flags: review?(gavin.sharp)
Blocks: 560562
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?
(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.
Attached patch patch v2 — — Splinter Review 
made the suggested changes (BrowserToolboxCustomizeDone, mTabstripClosebutton, mAllTabsPopup)
Attachment #440238 - Attachment is obsolete: true
Attachment #441639 - Flags: review?(gavin.sharp)
Attachment #440238 - Flags: review?(gavin.sharp)
Attachment #441639 - Flags: review?(gavin.sharp) → review+
Comment on attachment 441639 [details] [diff] [review]
patch v2

I didn't review the theme changes carefully (but I did test Mac/Linux).
http://hg.mozilla.org/mozilla-central/rev/6271a260562b
http://hg.mozilla.org/mozilla-central/rev/75afa4976c59
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a5
Attached patch fix a11y test — — Splinter Review 
Note that I landed this already to fix the failure on mozilla-central.
Attachment #441855 - Flags: review?(bolterbugz)
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.
Attachment #441855 - Flags: review?(bolterbugz)
Attachment #441855 - Flags: review+
Attachment #441855 - Flags: feedback?(marco.zehe)
Dão, could you describe shortly the UI changes of your patch?
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).
(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 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.
Attachment #441855 - Flags: feedback?(marco.zehe) → feedback+
(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.
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.
Status: RESOLVED → VERIFIED
Blocks: 562327
No longer blocks: 562327
Depends on: 562327
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?
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.
(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.
Flags: in-litmus?
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.
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...)
(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
Depends on: 562396
Depends on: 553390
(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
No longer depends on: 553390
(In reply to comment #118)
> Bug 457187
I meant bug 553390 for adding a customize option to the context menu.

Sorry for the spam.
(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.
Depends on: 562718
Depends on: 562723
Blocks: 577768
Big customization win, blocking+.
blocking2.0: ? → betaN+
Depends on: 990186
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: