150379 - So called "tab bar" should be made a proper toolbar or given the ability collapse / expand.

Status: VERIFIED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[Jason Bassford]

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?

Comment 1

[Hixie (not reading bugmail)]

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.

Comment 2

[Jason Bassford]

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.

Comment 3

[Hixie (not reading bugmail)]

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.

Comment 4

[Jason Bassford]

Attachment: 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.

Comment 5

[Jason Bassford]

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.)

Comment 6

[Hixie (not reading bugmail)]

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.)

Comment 7

[Jason Bassford]

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). 

Comment 8

[Hixie (not reading bugmail)]

> 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.

Comment 9

[Jason Bassford]

> 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.

Comment 10

[jag (Peter Annema)]

> 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.

Comment 11

[Hixie (not reading bugmail)]

VERIFIED WONTFIX per comments

Comment 12

[Jason Bassford]

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.

Comment 13

[Jason Bassford]

Marking invalid as per previous comment.

Comment 14

[Hixie (not reading bugmail)]

ok...

Comment 15

[Jason Bassford]

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.

Comment 16

[Asa Dotzler [:asa]]

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. 

Comment 17

[Jason Bassford]

Verifying resolution of all bugs I've reported.

Comment 18

[Simon Paquet [:sipaq]]

Taking QA Contact

Comment 19

[Pham]

*** Bug 216423 has been marked as a duplicate of this bug. ***

Comment 20

[Pham]

*** Bug 218280 has been marked as a duplicate of this bug. ***

Comment 21

[Bill Mason]

*** Bug 262508 has been marked as a duplicate of this bug. ***

Comment 22

[Dave Townsend [:mossop]]

*** Bug 347930 has been marked as a duplicate of this bug. ***