196322 - Allow preference for minimum width of tabs in tab bar.

Status: VERIFIED WORKSFORME

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[Jason Bassford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030306
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030306

Currently, on my system under a display resolution of 1280x1024 (I'm not sure if
this is system dependent or a built-in static number), Mozilla will "fit" 40
tabs along the tab bar before going into an overflow situation where no more are
displayed.  The issue of tab overflow aside (bug 155325), this is still far too
many tabs being displayed at once for their titles to be at all usable.  (They
may as well have no titles.)

I'm going to attach some screenshots to this bug.  One with 10 tabs open, one
with 20 tabs, and one with the maximum of 40.  Also another one showing what I
think should be the UI, as proposed at the end of this bug.

For the purpose of what I'm doing in the tab browsing activity shown by the
screenshots (which I do every day), having 10 tabs open still gives me enough
tab title space to be able to intelligently see which tab contains what data I'm
interested in.  By 20 tabs, the Bug number in the title has been truncated as
well as any part of the descriptive text - the tab title usability is no longer
 useful (it might still be, barely, if I had loaded sites other than those
titled "Bug" at the beginning).  By 40 tabs open, the usability is completely
gone for anybody regardless of what sites they're visiting.

What I recommend here is that Mozilla only show 10 tabs in the tab bar at a
time.  If there are more than that, then it should exhibit the same behaviour it
currently does when there are more than 40 - stop displaying them but leave them
in memory and have them accessible by <Ctrl><Tab>, etc.  This would this
preserve the ability of being able to intelligently click on a specific tab that
for which you're looking.

In terms of how I use tabs in this fashion, I generally start at the left and
deal with each page of information before going on to the next one until I get
to the end.  Whether I have 10 tabs worth of information or 10,000, I would
still do things the same way and it wouldn't matter to me (from that
perspective) how many tabs I have displayed at once.  (Having 40 shown is no
more a benefit to me than having 10 shown.  I'd rather have only as many shown
as are usable.)

Again, I don't know if the "40 tabs" is hardcoded or if it's machine dependent,
so I'm not sure what mechanisms should be put in place here.  If it's hardcoded,
just change the variable "40" to "10".  If it's somehow machine dependent then
the algorithm it uses to calculate the maximum number of tabs should be changed
to 25% of its current behaviour.

One last thing, which I'm going to include as part of this bug.  If there are
more tabs loaded than are currently being displayed, there should be some visual
indicator of this fact given to the user.  In the current situation of 40 tabs,
things are SO cramped that it almost doesn't make any sense to worry about that
sort of thing unless/until bug 155325 is addressed.  However, when the screen
space is less cramped, and actually legible, as it would be if this bug is
addressed, I think that it certainly DOES make sense to indicate that there are
more tabs in queue.  (Especially if a lower maximum is introduced and people
aren't yet used to it - if they aren't aware of the new behaviour they may just
assume that nothing is happening when they go to open a new tab.)

So, I would recommend adding a simple ">" symbol at the right of the right-most
tab to indicate that there are more loaded than you can see.  Perhaps hovering
over the ">" would bring up a tooltip indicating how many more tabs there are
"offscreen" or something like that.  (Clicking on it would do nothing - that
would be something that would have to be hooked up via bug 155325, which might
well do away with the ">" anyway in favour of some other method.)

Or, if the ">" is too suggestive of it actually doing something that it doesn't,
it could be a "?" or a "!" indicating that it's informational only.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Jason Bassford]

Attachment: 10 Tabs

Comment 2

[Jason Bassford]

Attachment: 20 Tabs

Comment 3

[Jason Bassford]

Attachment: 40 Tabs

Comment 4

[Jason Bassford]

Attachment: Proposed change to tab bar UI.

Comment 5

[Jason Bassford]

Another possibility for the "more tabs" indicator would simply be +1 (or however
many there are) with the tooltip reading "To access additional tabs use
<Ctrl><Tab> and <Ctrl><Shift><Tab>."  That way you'd know right away how many
more there are, and the user would be told how to access them when hovering over
the number.

Comment 6

[Chris Casciano]

I believe there's already a lengthy bug on UI of managing obscene #'s of tabs...
bugzilla's searching isn't cooperating with me at the moment

Comment 7

[Chris Casciano]

nm... the bug i was thinking of was the one you linked... i'm not clear why this
isn't a dupe of that bug but I'm gonna stay out of the middle of the ongoing
conversation... sorry for the spam.

Comment 8

[Jason Bassford]

> i'm not clear why this isn't a dupe of that bug

This bug is ONLY about limiting the number of tabs shown onscreen at any given
time.  The other bug is about methods of accessing tabs that exceed the current
maximum number displayed (whether by a using a right-arrow scroll, a drop-down
box, multiple rows of tabs, etc.).  I'm not concerned with methods of accessing
overflowed tabs here.

Comment 9

[Hanspeter Niederstrasser]

10 tabs on a 1600x1200 monitor look much different than in a 800x640 monitor. 
And whether 10 tabs fit or not also depend on the browser window width.  Your
attachment (id=116545) for 10 tabs spans 1280pixels.  I'd venture a guess that
few people have a window that wide (for example, I'm generally at ~700px on a
1600x1200 monitor, and 92% of statistics are made up).  I don't think that
setting a fixed # of tabs is a good solution.  At 700px/10tabs, with 16px for
the tab icon, ~15 for padding around the text, and ~10px per character, this
leaves enough space for less than 5 characters, exactly what you are trying to
eliminate.

IF a max number of tabs value is to be set, I believe using a min-width value in
px (or em for themes that change the tab font size) is a better solution.  Then,
the max # of tabs is independent on the width of the window yet still gives a
useful title.  Overflow can then be treated by whatever method bug 155325 decides.

For the record, Camino has a hard limit of 16 tabs per window.  Shrinking the
window to its bare minimum leads to tabs that are [windowbareminpx]/16.  This is
about 10px/tab for me.

Comment 10

[Jason Bassford]

> 10 tabs on a 1600x1200 monitor look much different than
> in a 800x640 monitor.

Absolutely, I never thought it would be different.   Which is also why I was
(implicity) asking if the current limit of 40 tabs is simply what *I* see with
my resolution, or if there is some kind of algorithm in place that sets a
maximum number of tabs based on what resolution you happen to be in.  Given that
the maximum *for me* is 40 tabs and that my ideal number of tabs is 10 - I also
suggested just changing the maximum number to 25% of it's current value.

Can you tell me the maximum number of tabs that you see when running in 800x600?
 If it's, let's say, 30, then I'd say that the maximum number that would make
things usable for *you* would be 7 across, not 10.

> I believe using a min-width value in px (or em for themes
> that change the tab font size) is a better solution.

Exactly.  We want a solution that works for everybody, in each person's
resolution.  My example should be taken and modified to a dynamic environment.

> For the record, Camino has a hard limit of 16 tabs per window.

Regardless of screen resolution?  If so, then perhaps Mozilla is the same way. 
So not only would this bug be about modifying the maximum number of tabs set,
but also about modifying the way in which the program calculates that.

(Honestly, I never bothered to change my own screen resolution and test out if
Mozilla changes its behaviour or not.  I suppose that I really should have - but
I assumed that other people, with different resolutions, and/or those who've
actually coded this part of the program would be able to answer that question.)

Comment 11

[Felix Miata]

Attachment: 30 Tabs are not too many.

Comment 12

[Jason Bassford]

Ah - your screenshot only shows, to me, that 30 tabs ARE too many in terms of
being able to read the titles.  The most of the title I can make out, for any of
the Bugzilla pages, is "Bug...".  There's no distinguishing one tab from the
other.  So if I'm trying to search for a specific bug number among the tabs I
can't quickly locate it by scanning the titles.  I'm forced to either click on
each one, or hover over each one to get the tooltip giving me the name. 
Whereas, in my screenshot of 10 tabs, I can clearly read "Bug 12345" on each of
them and locate a specific bug immediately.

(Yes, I know, in an overflow situation even where I can read all of the titles,
the one I'm looking for might not be present.  But I'd least I'd know it
definitely *wasn't* in my current set but "to the right" somewhere and, once
overflow is dealt with, I'd be able to locate it by going to the next page (and
quickly scanning all of those titles), etc.)

Comment 13

[Adam Hauner]

Jason: you are very probably forgetting site icons. I often use very much tabs
with different sites inside. Site icons are enough for me to resolve tab I want.

I'm recommending to WONTFIX hard limit for maximum number of tabs, but ability
to set this limit via setting hidden preference should be useful for some users.

BTW should be good to CC some of Mozilla's GUI experts - more heads, better ideas.

Comment 14

[Felix Miata]

My point is your opinion of how many is too many will differ from the opinions
of others. Get rid of the useless icons, as my screenshot shows, and much useful
space is regained.

I believe an inadequate hard limit (e.g. 10) on # of visible tabs to be a bigger
usability problem than needing to hover for a tooltip if I need a large number
of tabs open at once.

Maximum tabs showing may need to be a hidden pref with a default of the current
limit of 40.

Comment 15

[Jason Bassford]

> For the record, Camino has a hard limit of 16 tabs per window.

Not at all.  If every tab is from the same site (Bugzilla again as an example)
and there are so many tabs open that ONLY the site icon is visible - there is,
again, no easy way of distinguising one tab from the next.

> I'm recommending [against a] hard limit...[but] for a hidden preference.

I would find that acceptable - although I'm not sure why we would want anybody
to see something as unusable as the maximum number of tabs we currently have...

> BTW should be good to CC some of Mozilla's GUI experts - more heads,
> better ideas.

I'd be happy to.  Do you know who I should be bringing in here? <grin>

Comment 16

[Jason Bassford]

> Get rid of the useless icons, as my screenshot shows, and much useful
> space is regained.

The limit could always be changed based on whether or not the "useless icons"
<grin> are part of Mozilla or not.

While the equivalent of 10 tabs may be too few, I still argue that 40 is still
way too many.  However, having this be a (hidden) user defined pref (maximum px
width is better than static #) would certainly accomodate everybody here.

Comment 17

[Adam Hauner]

GUI experts: [e-mail] and probably [e-mail]. You should
also ask for help some of drivers (after 1.3 releases) or module owners.

Comment 18

[Felix Miata]

The limit can't be changed by users unless the programmers make a provision to
do so.  I'm sure if I had the hardware to support 2560x1920 I'd  not be pleased
with a hard limit of 40. I'm at 1024x768 now and not infrequently have at least
15 open at once in this mode. More than 20 isn't that rare either.

Minimum em, not maximum px. Px sizing has no place in space occupied by text.

Comment 19

[Hanspeter Niederstrasser]

> Which is also why I was (implicity) asking if the current limit of 
> 40 tabs is simply what *I* see with my resolution, or if there is some 
> kind of algorithm in place that sets a maximum number of tabs based on 
> what resolution you happen to be in.  Given that the maximum *for me* is 
> 40 tabs and that my ideal number of tabs is 10 - I also suggested just 
> changing the maximum number to 25% of it's current value.

The number of tabs seems to be [windowwidth]/[smallest tab size that will still
fit the tab icon].  I can't find any minimum size settings in the CSS for
Modern.  Though there might be some code in the XBL, but I don't know what to
look for in there.

> Can you tell me the maximum number of tabs that you see when running in 
> 800x600?  If it's, let's say, 30, then I'd say that the maximum number 
> that would make things usable for *you* would be 7 across, not 10.

I'm not at 800x600, but 50 tabs fit on a 1600x1200 window on MacOS X.  Tab51
overflows.  17 tabs is when I felt the title was no longer useful (subjective),
even though there were still letters showing (though for me, I don't care if the
tabs are too small to show text).

Also, I think you meant "the max number that would make things useable for *me*
on *your* settings would be 7 across".  This is a key distinction that must be
made if this RFE is implemented.  It cannot be based on a programmer's specific
situation, or even a limited subset of possibilities.  I know you understand
this, but I want to make it clear so that it is recognized as an important
factor when considering this RFE.

> Exactly.  We want a solution that works for everybody, in each person's
> resolution.  My example should be taken and modified to a dynamic 
> environment.

I see the benefit with what you are trying to establish.  However, I don't
believe that hardcoding a max # of visible tabs is the best solution, which is
what you suggested originally.

> > For the record, Camino has a hard limit of 16 tabs per window.
> 
> Regardless of screen resolution? 

Yes (not tested in a while).

> If so, then perhaps Mozilla is 
> the same way.  So not only would this bug be about modifying the maximum 
> number of tabs set, but also about modifying the way in which the program 
> calculates that.

Just from looking at how it functions, Mozilla seems to just have an implied
minimum width in that the tab can never shrink to hide the icon and its padding.

Comment 20

[Jason Bassford]

Comment 15: My first line should have read "> you are very probably forgetting
site icons."  Something messed up with my quoting.

As far as I'm aware, MPT isn't around anymore to CC: actively.  (I could be
wrong, but he's at least cut back recently.)  However I'll add Marlon here.

Marlon: As always, it feels "odd" to add somebody to the CC: list without their
awareness.  (I think I've complained the few times people have added me without
my permission.)  So I'll apologise in advance if you didn't want me to do this...

> More than 20 isn't that rare either.

More than 60 isn't that rare for me.  But the point here is not being how many
tabs I have open, but how many I want to view on the screen at once for the sake
of preserving legibility.

> Minimum em, not maximum px.

Er, yes.  Of course I'd meant to talk about minimum (not maximum) tab width.  I
got confused by the maximum number of tabs...

Comment 21

[Hanspeter Niederstrasser]

Lots of mid air collisions when I was writing my last post...

The following code put into userChrome.css or a theme will give a useable
minimum size for tabs (and therefore max # displayed):

tab { min-width: 9em !important; }

This is easily modified by the user and can also be changed by theme authors. 
It does not require a new hidden pref or a programmer.  I recommend closing
since a solution already exists.

Comment 22

[Jason Bassford]

> I think you meant "the max number that would make things useable for
> *me* on *your* settings would be 7 across".

Yes, my mistake.  Obviously, what I want is by no means what everybody else
wants and I hadn't meant to imply it was.  Thank you for pointing that out. 
(I'd only been trying to make a statement about the number of tabs relative to
the screen resolution and messed up the implications.)

It seems obvious to me now that replacing one arbitrary maximum number with
another arbitrary maximum number is simply exchanging one set of personal
preferences "foisted" on everybody for another set.  And I'm not going to argue
about how more people would probably like half the number we currently have,
because that's only causing debate that shouldn't be here.

So, with that in mind, I'm changing the summary to better reflect what seems to
be a concensus.  That we should have the ability to change the minimum width of
the tabs displaye in the tab bar, as per our own system's screen resolution, and
our own browsing preferences.

> Mozilla seems to just have an implied minimum width in that the tab
> can never shrink to hide the icon and its padding.

My suggestion, then, would be to allow a preference that would let the user set
the minimum width of each tab to be as it is now (the icon and its padding) PLUS
a user-defined number of characters in the title text.  (If "10 characters", as
I'd set it personally, can be made to mean anything when considering
proportional fonts.)

Comment 23

[Jason Bassford]

I feel like I'm in the middle of a rendition of the "Banjo Song" here.  Comments
are flying around at an ever increasing rate...

> The following code put into userChrome.css or a theme will give a useable
> minimum size for tabs

Excellent!

> I recommend closing since a solution already exists.

Well, it's certainly a workaround (and I'll be raising a pint to "hn" shortly) -
I don't know if I'd consider it a proper resolution.  Perhaps we could assign
this to [e-mail] and target it at future, dependent on bug 155325? 
While they are separate issues, I have no doubt that once overflow is dealt with
there will be more call for wanting to have this kind of setting better exposed.
  Or I could be wrong.

If nobody else thinks that this is worth pursuing (at least at some future
point, perhaps once overflow is implemented) I'll go ahead and resolve it
WORKSFORME.  Otherwise, I'll follow the above.

Comment 24

[Felix Miata]

I don't think you're going to get a  consensus that the pref you're requesting
is needed, and the drivers don't like new pref requests as it is. userChrome.css
works. I suggest WFM.

Comment 25

[Jason Bassford]

Okay, marking this as WFM.  Anybody who thinks that it should be an actual pref
is free to reopen.

Note: I will be filing a new bug to address the "+X" feature I mentioned here,
indicating how many tabs are hidden to the right, as well as one to decrease the
right margin of the tab bar so you don't get the close tab button drawn on top
of the right-most tab.

Comment 26

[Jason Bassford]

.