From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020607 BuildID: 2002060704 I believe that the "tab bar" should be made into a proper toolbar. Currently, there are some problems accessing certain Mozilla functions when the preference "Hide the tab bar when only one tab is open" is checked. If the tab bar is always open then there would be no question, for instance, that you could always drag a URL to the "tab bar" and have the link opened in a new tab. But if the tab bar is not visible this is not possible. If it were to become a proper Tab Toolbar, that you could show or hide under the View menu, then you'd also have the ability to collapse it when you are only viewing one site, making its real estate far less than what currently happens when the tab bar is visible when you only have one site open - and there would also be a spot on the screen to which you could drag a URL. (Opening a new tab would expand the Tab Toolbar if it were already collapsed - although, I suppose, the user could collapse it again if they chose.) This would also address several other open issues about tabbed browsing. If the Tab Toolbar were shown, that could be treated as a user preference to use tabbed browsing. That would also validate comment 10 bug 149297 (which I had objected to in comment 18 bug 149297 because of the screen real estate footprint of a single tab as it currently stands, but which I would endorse given the ability to collapse the Tab Toolbar). If somebody never uses tabs, they can simply hide the toolbar. If a user open a tab via the menus, despite the fact that the toolbar is hidden, they could be prompted to view the Tab Toolbar along with the tab. Otherwise, to make life simple, I believe that the new tab should NOT be created and the Tab Toolbar should remain hidden. In a related situation, if multiple tabs are already open, with the Tab Toolbar visible, and they unchecked View -> Show/Hide -> Tab Toolbar, all tabs would be closed (since I don't believe there should be open tabs if the Toolbar is not visible) after having been issued a warning about this. I believe that addresses all scenarios I can think of. This would certainly entail some logistic troubleshooting, but I believe it would help solve some other bugs if this were implemented. As it is, the "tab bar" is only a quasi-Toolbar and I believe it would benefit from being elevated to "full" Toolbar status. Do we currently have the technical ability to create a dynamic toolbar as this would imply? If not, can we, instead, make this bug about adding the ability to collapse/expand the existing tab bar?
The tab bar is not a toolbar at all at the moment. I am not sure it really wants to be, either. Imagine the day where we have configurable, movable toolbars. How would moving this toolbar make sense? Also, I fear that this proposal would result in way more user confusion that required. I think the issues raised are best dealt with in other ways. I'll let jag make the final call, though, since he's the module owner.
Even if it's not a "toolbar" it could still have many of the attributes of a toolbar. Viewing the tab bar when there is only one site being viewed is annoying because the single tab takes up all of the space. If it could be "collapsed" as a toolbar is collapsed (at least until there are multiple tabs open) then, I think, more people would use it because the UI wouldn't be so "annoying" with a single site. Also please note that the bug is not JUST about making the tab bar into a toolbar. As per the Summary and Description - if making it a toolbar is out of the question, then just being able to collapse it (in some fashion) would be sufficient.
What I meant was that _conceptually_, the tab bar is not a toolbar. Collapsing is something that toolbars do, not something that tab bars do. There is no reason to have to show the tab bar when you only have one site open, indeed I don't. If you want to drag a URI to Mozilla from an external application (something I only rarely do) and need a new tab to open, then simply open a new tab first, then drag the text. I'm not sure I understand what the advantages are of making the tab bar collapse, and in particular, how those advantages counter the disadvantages of added confusion and ambiguity.
Created attachment 87043 [details] Proof of concept picture. Created an attachment showing "proof of concept" for my idea. Notice now much better the browser window looks (less cluttered) with a single site being viewed, yet with the small tab bar visible. (Which can be used to drag and drop URLs to.) As mentioned in the Description, having this set so it's either "on" or "off" via the View menu is the perfect way of accomodating the various bugs that depend on whether or not somebody uses tabs. Rather than having to add an additional preference (for not showing any tab UI) - you could actually REMOVE a preference if this were in place (Hide the tab bar when only one tab is open). (The only reason I currently *DO* hide the tab bar when I only have one tab open is because I don't like how much real estate it takes up - it doesn't make "sense" to me to even see a tab - unless I'm viewing two or more sites.) With a lower impact one site tab bar, comment 10 bug 149297 makes much more sense. You could also accomodate those people who don't ever want to see New Navigator Tab / Open in New Tab. If you don't have "View -> Tab Bar" selected, those menu options will never appear.
Clarification: In the JPG I attached, the first picture is meant to be what you would see if you only had one tab open; the 2nd picture is what happens when you add a 2nd tab. (Although, theoretically, the first could also be what happens if you collapse the tab bar with two tabs, it only showing the current one - but that wasn't the main point of what I'd meant to illustrate.)
I understand what you mean. I just don't agree with it. What are the advantages? The only one I've seen explained is that it lets you drag URIs to the tab bar, but as I said, that's a limited use case and can already be achieved by just opening a tab first (or, if you do it a lot, having the tab bar always visible.) BTW, try making a sample screenshot with the sidebar and links bar open. (Note: if you say "bug XXX comment YYY" then bugzilla linkifies it correctly.)
Okay. The drag to the tab bar feature is only a very minor one and isn't what I see as being a benefit here. (It's only a bonus.) I'm certainly not arguing this because of that alone. What I see as the benefit of this is that there is an explicitly defined preference set by the user that they want to use tab browsing. If they use tabs, they'll set View -> Show/Hide -> Tab Bar. If this is not set, then they won't. This leverages the use (or non-use) of the Tab Bar in such a way that it can be clearly indicated whether or not the tab browsing functions that are in dispute in various bugs be shown in the UI or not. What I'd been meaning to show by referring to bug 149297 commment 10 (my apologies for getting the plain text linkify order wrong) is that there is a use for always having the tab bar exposed. (This comment is not about drag and drop but is about having something in general happening - tab functions displayed - only if the tab bar is being used.) It's good for everything having to do with tab browsing in terms of debate about wanting (or completely removing) tab references in the UI, and easily addressed functions. (There may be enhancement requests in the future to add static capabilities to the tab bar - ala the Navigation Toolbar, and so on - even though I can think of none at the moment. Having the tab bar always visible would aid in that.) The visibility of the tab bar would also greatly help new users to Mozilla learn about the existence of tabs. (I'm assuming that the tab bar would be viewed and collapsed by default.) It would be collapsed so as to leave as small a screen footprint as possible when viewing only one site - but it would be there so that they could expand it and see what it does. (As, I hope, it would automatically expand is a 2nd tab is viewed.) If they see one tab, I'm sure most people will understand that means that you can have more than one tab. Currently, you have "Open Link in New Tab" in the context menus, and "New Navigator Tab" in the File Menu, but this is just another way (and more obvious to the graphically inclined) to discover it. Yes, there is a bug open about setting a preference as to whether or not you want to use tab browsing at all or not. (Bug 124973) But, rather than having this as a preference proper, I think it would be much more visible to have it implicitly applied by the users choice to show or hide the tab bar. I think having the tab bar always shown is what the behaviour should be when tab browsing is in use. The reason that I'm "lobbying" for having it collapsible is because I simply don't like seeing the tab bar *at present* when there's only one tab - it's too distracting and if having it always visible in its current state were hard coded there'd be a slew of complaints. But, if I'm a tabbed browsing user and it has the much lower visible impact of being collapsed when only a single site is viewed I *do* find that acceptable and wouldn't complain about it being there. Especially if having it present enables other features. (The trade off of the much lower visible impact is more than adequate.) If you think that you'd still not like seeing the collapsed tab bar when viewing only one site that's something else. But I do think that a "Tabs, yes, have a tab bar and show all tab UI in menus; tabs, no, don't have a tab bar and don't show any tab UI in menus" is a good way of reducing the complexity that's being introduced from the various other bugs out there trying to accomodate individual's tab browsing preferences. (It makes somebody's use of Mozilla very clear and removes objections about having one person's style "infringe" on another person's when they see "intruding" UI elements.) If you still can't understand the advantages I'm trying to get across I pretty much can't describe what I'm thinking any better. Somebody else will have to help me out - or we can just wait for this bug to be closed if jag also doesn't see my point. If it would help, assuming this latest explanation of mine has made no more sense to you than my previous attempts, I could list the bugs I can think of that could benefit from this kind of approach (in addition to the two I've already mentioned).
> If they use tabs, they'll set View -> Show/Hide -> Tab Bar. If this is not > set, then they won't. What's wrong with the current set of prefs? I'm not convinced we _want_ to hide any menu items at any point. Why would that ever be a good idea? Modal UI is considered very poor form. And the reason to show the tab bar (as per bug 149297 comment 10) is so that people discover tabs; if you then collapse it, people are merely going to think it's silly for us to have a gray bar in the way.
> What's wrong with the current set of prefs? There are none that cover this. That's why we have bug 124973. Some people want a tabbed browser, others want a tabless browser without the tab UI. > is so that people discover tabs; if you then collapse it, > people are merely going to think it's silly for us to > have a gray bar in the way. Does the default Mozilla install have "Hide the tab bar when only one tab is open" unchecked? If so, then this is more about aesthetics than anything else (which is still valid); if not, then having a collapsed tab bar is better than showing none at all. The "grey bar" is far less intrusive than the "grey bar" WITH a single tab.
> There are none that cover this. That's why we have bug 124973. Some people > want a tabbed browser, others want a tabless browser without the tab UI. Well, I'm not going to hide menu items for tabbed browsing, I don't see the need to further complicate our code for that. Someone will write an .xpi that will do that, and then those users who don't want to see any tabbed browsing related UI can install that and be happy. As for whether to show the tab bar (or some placeholder for it) by default in Mozilla, I don't think Mozilla users have trouble discovering the feature, and those who like it to always be there (for whatever reason), have no trouble changing the pref from its default of hiding the tab bar when only one tab is open. In Netscape we may actually show the tab bar by default (in full), in which case the close box will double as an easy way to hide the tab bar, so even though it may be considered intrusive, it'll be easy to get rid of, and easy to show again (e.g. by opening a new tab, something your proposal conflicts with, or a new menu item under View -> Show/Hide). I strongly suspect that having a collapsed (tab) bar by default will come across as sloppy, and will make the contents undiscoverable. My suggestion is WONTFIX for this bug.
VERIFIED WONTFIX per comments
FWIW: This bug has been addressed by the fix for bug 112769. Now that there is something else on the tab bar (an open tab icon on the left) the "single tab" is no longer on its own and it no longer looks inappropriate. I am reopening this bug and marking it invalid, since my original complain is no longer valid.
Marking invalid as per previous comment.
Reopening to see if this applies (is acceptable) to Phoenix, now that customizability is available. Note that this bug is now morphing from reasons given in comment 0 - but since it's my own bug I figure I can do that. It would be nice to be able to add/remove/relocate buttons with respect to the tab bar. -> Phoenix where this bug has the only (current) hope of surviving.
I spoke with the Phoenix module owner and peer and this isn't gonna happen for Phoenix. Neither is the menubar or the status bar going to be added to the customize tool. Dave did say that he would be adding ID hooks (or something like that) to more places so that Phoenix extension developers would more easily be able to insert items to those locations.
Verifying resolution of all bugs I've reported.
Taking QA Contact
*** Bug 216423 has been marked as a duplicate of this bug. ***
*** Bug 218280 has been marked as a duplicate of this bug. ***
*** Bug 262508 has been marked as a duplicate of this bug. ***
*** Bug 347930 has been marked as a duplicate of this bug. ***