268213 - Decrease minimum tab width (allow more tabs before invoking overflow menu)

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Tabbed Browsing, enhancement)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041106 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041106 Camino/0.8+

With the new tabs in the 0.8+ nightlies, the smallest width tab can have before
the overflow menu begins is ca. 100 px (it varies with screen size, resolution,
and Camino window size--this number is from a 17" PB, 1440x900, Camino at full
width--the minimum width increases as the window size decreases).

There's been some grumbling in the MozillaZine forum both about the overflow
menu itself and about the fact the new tabs don't shrink as much as the old ones
did (or that one can't get as many tabs displayed on the tab bar as in the
past).  The overflow menu is also a little "awkward" because one only sees
"part" of the interface for the current tab if it's in the overflow menu--the
location bar part, but not the active tab (on the tab bar) itself (still a huge
improvement over the old 16 tab limit+extra tabs in new windows, though!).

In order to address all of these issues, it would be nice if the minimum tab
width could be decreased.  My personal preference would be to decrease the
minumum tab width to just the amount of space needed for the close box and the
favicon and appropriate padding.  This (or really any decrease in the minimum
width) is probably dependent on bug 183279 (tooltips for tab titles) and  bug
162893 (favicons referenced by LINK element are not displayed) being fixed, as
those two bugs provide info that would make "tiny tabs" distinguishable from
each other easily (sight or mouseover).  

This takes the strenghts of both styles of tabs and makes the result better (I
think).

Reproducible: Always
Steps to Reproduce:
1.  Open a bunch of tabs

Actual Results:  
Tabs never get smaller than ca 100 px, and a certain small number of tabs--8, or
half of the old style tabs, at my usual window width, but this varies depending
on screen width, resolution, and window width--before the overflow menu is invoked



Expected Results:  
Shrink tabs' widths to approx. close box+favicon+padding before invoking the
overflow menu

Comment 1

[Peter Yang]

I agree; I think the minimum of 100px tabs is somewhat low, as I frequently have
more than 9 (in my case) tabs open. I don't know if limiting it to just the
favicon and the close button is reasonable, but I don't think 100 px is very
reasonable either.

If we decide on keeping the current tab width, I would recommend that the tab
bar always keep the current page highlighted, shifting if necessary. Example: If
Camino overflows at 8 tabs, and I'm at tab 10, the tab bar should display tabs 9
through 16. There should be overflow arrows on both the left and right sides
that work just like the current overflow arrow. (I can file a separate bug on
this if requested.)

Comment 2

[Jasper]

The problem with this bug is that everybody has different needs. The main reason
it is 100 px at the moment is to make sure website titles are well visible and
are not cut. But maybe we could decide to use 75px instead as the minimum tab
width. I guess we need to test this a little.

It's an easy enough fix even I can provide.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #2)
> The main reason
> it is 100 px at the moment is to make sure website titles are well visible and
> are not cut. But maybe we could decide to use 75px instead

I understand; I think 100px is really the smallest possible to keep a useful
title--y'all make good decisions! :)  75px looks to me like 4 characters +
ellipsis (vs 8 + ellipsis at 100px), not enough :(

That's why I suggested that shrinking should be dependant on fixing bug 183279
and bug 162893 (although I don't think I have the power to add that dependency
formally, and certainly couldn't input them on the "reporting a bug" form). 
Then there would be alternate methods of displaying the title and recognizing
the site.

Comment 4

[waverider]

Attachment: suggestion : add hidden user_pref for minimum tab width

I want to change minimum tab width.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Since I now have the power to do so, adding the dependency on bug 183279 and bug
162893.  

This is not a "hard" or technical dependency but rather one that ensures a good
UI/ease-of-use (make the tiny tabs distinguishable visually when the displayed
titles are 3 characters long...).

Comment 6

[John Mellor (Jomel)]

In Mozilla/Firefox minimum tab width can be set with a userChrome.css statement
(see bug 196322).

Comment 7

[Chris Lawson (gone)]

Here's another vote in favour of a (hidden) preference to allow users to set a
minimum width.

Once we get bug 183279 fixed, the necessity of having wider tabs really goes out
the window, IMO, as the tooltip will provide a full title and URL.

cl

Comment 8

[Desmond Elliott]

What is the status of this bug? Nobody appears to have reviewed the patch that already exists and I am constantly prodding around BrowserTabBarView.mm so we may as well get this sorted.

Comment 9

[froodian (Ian Leue)]

The status is that this patch just reduces the minimum width.  We decided in the big meeting and the wiki conversations that followed it that what we should be doing is leaving the minimum width at its current value, but providing the user some way to change that (either via about:config, or or with a resize-drag on the edge of any tab)

Comment 10

[froodian (Ian Leue)]

Oh, I'm sorry.  Looks like this patch does add a hidden pref.  So the status is that we should decide whether that's what we want, or if we want the minimum tab width settable via the drag-on-edge-of-a-tab method.  I support the second.  I think it's an intuitive, unobtrusive, and shiny way of changing the width of all tabs.

Comment 11

[Desmond Elliott]

I am not currently working on this, freeing it up.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 13

[Chris Lawson (gone)]

(In reply to comment #10)
> Oh, I'm sorry.  Looks like this patch does add a hidden pref.  So the status is
> that we should decide whether that's what we want, or if we want the minimum
> tab width settable via the drag-on-edge-of-a-tab method.  I support the second.
>  I think it's an intuitive, unobtrusive, and shiny way of changing the width of
> all tabs.

Presumably the latter would have to create a pref of some sort anyway, so it really addresses both. I think if we're going to do this, making the edge of tabs draggable is the most Mac-like way to do it.

This sort of got lost in the last couple years, but we probably ought to make a decision one way or another. I'm still in favour of *something*, but it's not a particularly common request amongst our users (maybe four or five requests on the forum in the past two years), so that might be a pretty good argument for WONTFIX.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Tab width comparison, Camino vs. Safari

My feelings on this have changed substantially since comment 0; overflow has improved considerably, and we have scrolling and rearranging now, too.

At my standard window width (883px), our tabs are all of 1px wider than Safari's (103px vs 102px) and we show the same number of tabs (8).  At a very small window width (the smallest window that allows 2 tabs + scroll/overflow widgets), our tab width is 99px.  We basically allow for 8 characters of title text (or 7 characters and an elipsis).

I can't imagine tabs being usable much smaller than this.

Second, if we allowed user-resizing, we'd need to condition it on some modifier (option?), because between tab dragging and site icon dragging and close-button clicking, normal click-and-drag behaviors are pretty crowded on the tab.

Finally, I'm not sure there's enough demand to support the amount of work this would take to implement (reworking the tab drawing/sizing code + implementing the resizing mechanism/animation).  Frankly, I'd much rather the time/effort that would be required be put towards animation for scrolling tabs and the ability to scroll the tab bar while dragging to rearrange.  My vote is WONTFIX.

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think we should just WF this, per thoughts a year and a half ago.  Bug 628418 is probably a better way to address whatever part of this that still remains for those 5 people, I think.