Closed Bug 155325 (taboverflow) Opened 22 years ago Closed 14 years ago

Very many tabs overflow UI is not fully developed

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dcary, Unassigned, NeedInfo)

References

Details

(Whiteboard: [need info][asaP1][Hixie-P0] Read all comments here, only post new information.)

Attachments

(8 files, 2 obsolete files)

a simple fix
6.25 KB, patch
Details | Diff | Splinter Review
Patch for chrome-dir
6.81 KB, patch
Details | Diff | Splinter Review
Sorry, this is the patch!
7.22 KB, patch
Details | Diff | Splinter Review
Crazy Browser's stacked tabbed browsing in action
2.96 KB, image/png
Details
Mozilla-1.3 many tabs
23.58 KB, image/gif
Details
How Epiphany/Gnome does it
186.38 KB, image/png
Details
patch (based on previous patches here)
13.16 KB, patch
db48x
: review-
Details | Diff | Splinter Review
Sceenshot of the bug in Firefox 3.0b2
154.38 KB, image/jpeg
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    2002052306

When lots of tabs are open (this is not very many on low-resolution screens with
windows not full-screen), only the leftmost N tabs are accessible. There needs
to be some way to access the rest of the tabs (other than closing the leftmost N
tabs).

Reproducible: Always
Steps to Reproduce:
1. Hit Ctrl-T ``many'' times. (If you have a low-resolution screen, and/or you
shrink the browser window to a narrow column, the ``problem'' starts to occur
after only 10 or so tabs are opened).
2. Type a web address into the address bar in the current (``rightmost'') tab.
3. Click the leftmost tab to activate it.
4. Try to activate the ``rightmost'' tab.

Actual Results:  Only the leftmost N tabs are accessible, unless I close some of
them.

Expected Results:  Umm... good question. Some ideas were floated in bug 106927.

Bug 106927 is a plea for fixing a bug ASAP: the right side scroll bar
disappearing. This request for enhancement is a place for discussing how the
tabs should be displayed in the pathological case of the user opening too many
tabs to view at once, and/or the user shrinking the window too narrow to show
all the tabs.

-- 
David Cary
Status: UNCONFIRMED → NEW
Ever confirmed: true
I always thought the best idea was horizontal scrolling once the tabs overflowed.
*** Bug 157868 has been marked as a duplicate of this bug. ***
*** Bug 157872 has been marked as a duplicate of this bug. ***
The UI people suggested we use a drop down menu at the end of the tab bar if
there are too many tabs:
      _____________   __________   _____________   ____________   ____
  _N_/_mozilla.org_\_/_BBC_News_\_/_mozillaZine_\_/ nawl: Ad...\_[ >> ]_X______
 |                                                               | ln.hixie.ch |    
 | N A W L                                                       | Bug 155325  |    
 |                                                               |:Bug:List::::|
 | « Do you approve of violence, Miss Boon? | Main               '----------|\-'
 |                                                                        |  \
 |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|
Whiteboard: [Hixie-P0]
i'd like to propose worksforme, since you can in fact access those tabs using

the keyboard ;-) -- ctrl-pagedown.

but seriously, do we need more bugs for this?
the drop-down menu is a good idea(!); and it gave me another: what about
grouping tabs by domain/IP if more then one is opened per domain

      ______________   ______________   _________________   ________
 [N] [ Bugzilla.Moz ] / www.site.com \ [ www.search.ch   ] [   >>   ] [X]
 |   | Bug 148293  |                   | search results |  | google |     |
 |   | Bug 155325  |                   | search query   |  | other  |     |
 |   | Query ...   ¦                   '----------------'  | tabs   |     |
 |   '-------------'                                       '--------'     |
 |                         Google                                         |  
 |                                                                        |
 |                                                                        |
 |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|
comment on comment #5:

you're right, you can access them with the keyboard, but...
... it is not user-friendly
... it doesnt look really nice

recently a colleague told me after using mozilla on this computer (she is IE
user), that mozilla works like every browser do (she is not an 'computer-freak',
just a user) and the only good thing she remarked were TABS

=> Tabs are a strength in mozilla and should be enhanced wherever it is able to
do so - normal users like such features (no amateur would ever ask if something
is opensource, has DOM-support, ... - an amateur would ask how something other
can enhance his/her work on the computer)

=> Me myself, i like also to search for a method how to enhance everydays tasks,
like browsing on the web


A few things:

As an overall comment, I'd like to see whatever solution we come up with "kick
in" sooner than it would if based on current behaviour.  At the moment, the
width for the tabs gets horribly cramped before the UI stops showing any more. 
I don't know if this is hardcoded or based on each computer's screen resolution,
but get overflow happening at 40 tabs.  I'd rather have our overlow take affect
about halfway through what it does right now, 15 or 20 tabs, so that tabs widths
and the UI both remain somewhat usable.

The dropdown menu might be a good idea.  (I can't really decide if, personally,
I'd rather scrollbars or a dropdown menu.)

I certainly think that we should NOT be grouping anything by IP or any other
category in the dropdown box alone.  Such grouping should be proposed in a
separate bug and would, I think, affect all tabs.  (I'm not in favour of it in
general, but that's another issue.)

Thinking in terms of extreme cases - many, many tabs - I think a dropdown box
should offer the following kind of entries:

1-20
21-40
41-60
61-80
81-100

And so on, rather than a single entry per tab with its title.  The range would,
of course, be based on how many tabs have been determined to display onscreen at
once prior to reflow.  That way, you jump from one "screen group" to the next. 
If you use single tabs and titles, you'd have to make the width of the dropdown
box quite large to accomodate tab titles.  This way, the width remains pretty
constant and takes up less space.
Just looked at grouping by tabs comment 6 again.  The picture shows what looks
like tabs within tabs.  (There are multiple tab entries in the "active" tab bar
in addition to the dropdown list itself.)  That behaviour has already been
marked as WONTFIX in other bugs.
you're right: there must be a 'minimal tab size'

apropos a menu like this:
1-20
21-40
41-60
61-80

it is of course a good idea, but there is one problem:
when someone uses 80 Tabs - how can he/she find a tab in this 'chaos'?

The d-d menu should help out if a certain 'minimal tab size' is fallen short and
the titles cannot be read any longer 

the grouping by IP or something else is only a good idea for people who are on
the extreme (e.g. more than 30 tabs in one window) where this sorting give
somebody an idea what is open and where it can be found

about the 'too long titles in the [ >> ] tab':
you are right, but what about using a 'maximal menu size' and if the title
doesnt get in, using instead of 'the title of this page is too long' something
like 'the title of this pa... ' -> the webmasters are wrong by making such too
long titles - but in most cases the needed information is in the first 20 letters


'picture' from comment #6 as it should be when a page is visited on the internet

 [N] [ Bug 155325  ] / www.site.com \ [ www.search.ch   ] [   >>   ] [X]
 |          ^                                                             |
 |          ¦ active tab                                                  |
 |                                                                        |
 |                                                                        |
 |        Bugzilla Bug 155325                                             |
 |                                                                        |
 |        Very many TABs UI not fully developed                                
                                 |
 |                                                                        |  
 |                                                                        |
 |                                                                        |
 |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|
> when someone uses 80 Tabs - how can he/she find a tab in this 'chaos'?

Good question.  Regardless of *what* solution we implement, I think the user
with that many tabs open would always have difficulty locating anything.  I
don't think displaying the tab names would be much more help than the tab ranges
for somebody who's opened up that many tabs.  In fact it might even be more
confusing.  Anyone who's got themselves in a position of having 80 tabs open
isn't likely to even be aware of any of the tab titles - they would have opened
up a huge series of links from a reference page.  Frankly, I don't think that
they'd ever want to find a *specific* tab in such a case (they'd just want to
scroll through them in general), nor would they know its title if they did.  The
only thing they *might* know would be its general position in "the pack".

With so many tabs open, the only "useful" thing to do, IMHO, would be to
reposition the active tab bar "viewpoint" to various positions (at the end, in
the middle, etc.) and, with this result in mind, a numerical range would better
serve.  If we just use names, and I have 80 tabs open (somebody please shoot me
if I ever do that) and I want to get to around the 3rd quarter section of tabs,
it would much easier to pick out "41-60" than it would be to scroll down until I
got to what I estimated was that area.

> The d-d menu should help out if a certain 'minimal tab size'
> is fallen short and the titles cannot be read any longer 

Are you suggesting that we implement the dropdown menu regardless of whether or
not we've overflowed?  I had thought that our fix would only take affect in the
event of an overflow...

> the grouping by IP or something else is only a good idea
> for people who are on the extreme

I would only find that more confusing than anything else.  (Particularly if I
wanted to get to the "3rd quarter" range of tabs - how could I do that if they
weren't sorted in sequence?)

We want to implement something simple and easy to navigate with, not something
that would require much thought on the part of the programmer or user.  This
should be a very basic fix.
I'm not sure this has been suggested yet - it doesn't seem like it's been
mentioned in this discussion yet:

What about just arranging the tabs vertically like Opera? Arranging them
vertically allows for many more tabs to be visible at any one time, and they can
all be readable.

As far as what to do when too many tabs are displayed (whether vertical or
horizontal), I'll let you guys worry about that. I just think that much better
economy is acheived with vertical display.

Are there good reasons why this can't be done? I'm surprised to be the first
person to mention it, especially since Opera does it so efficiently.

Jeff
I think that what we're looking for here is a solution that won't rely on the
number of tabs you're using being finite.  (Or, rather, a solution that only
works up to X.)  Whatever we come up with should work, in theory, with hundreds
or thousands of tabs.  While arranging tabs vertically rather than horizontally
may increase the possible number of tabs displayed prior to overflow by some
degree, it won't actually solve the problem in the end.
******COMMENT POSTERS: READ THIS********
Now that I have your attention...
A lot of what is being discussed here has been covered a lot in bug 106927.
I recommend that you (whoever is desiring to post a comment) 1) read through the
discussion in bug 106927, 2) read through the discussion in this bug, and 3) if
you still have something that hasn't been said before, take the discussion to
news://news.mozilla.org/ah4od3$k4o1@ripley.netscape.com .

To reiterate, bugzilla is not the place to discuss UI enhancements (even though
it is [ab]used for that frequently). Once a tenable solution has been worked out
in the newsgroups (preferably with agreement from some mozilla UI gurus), come
back here with a design recommendation.
Sorry for the spam... I forgot to mention: That message is in
netscape.public.mozilla.ui. The subject is "Tabbed Browsing: Gracefully handling
tab overflow".
Based on discussion in the UI newsgroup, and in reading through discussion in
bug 106297, it SEEMS to me as if more people than not want to have multiple tab
rows.  The solution to overflow in *that* situation is to have a vertical
scrollbar that scrolls up/down through the various tab rows that become
available.  The solution as to how many rows to show, is solved by having a
resizable tab row "window".

Multiple rows seems to be the majority opinion, and vertical scrolling and
window resizing are good methods of addressing problems related to that approach.

Obviously, however, there will never be 100% agreement on a solution here, so
there will always be somebody who is unhappy.  It's not clear how to proceed
from here.  That said, I'm sure that everybody WOULD agree that any of the
discussed methods of addressing overlow would be better than what we have at
present.  Perhaps we should just pick the method that's easiest and quickest to
implement from a programming standpoint, close this bug, and then deal with
other approaches/issues once we actually do have at least SOME solution in place.
*** Bug 156608 has been marked as a duplicate of this bug. ***
Attached patch a simple fix — — Splinter Review 
Here is one simple solution using a drop down menu at the end of the tab bar if

there are too many tabs.
(The patching might not work properly with Classic skin because
of a bug in PatchMaker. )
Grouping tabs (comment #6) is a capital idea, but you can still have too many
tabs so different there will be more groups that you can display. So it can only
be an additional feature.

Drop down menu (comment #4) will become confusing when I reactive a tab from the
drop down menu and hence change the order of the tabs. Plus there will be a lot
of problems with manual tab reordering.

I suggest a solution similar to comment <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=106927#c53">#53</a> (with
screenshots!) of bug #106927:

  [N] [|<] [<<] [<] [Tab k] [Tab k+1] [Tab k+2] [>] [>>] [>|] [X]

[>] should make the tab row move one to the right:

  [N] [|<] [<<] [<] [Tab k+1] [Tab k+2] [Tab k+3] [>] [>>] [>|] [X]

[>>] should make the tab row move "one page" to the right:

  [N] [|<] [<<] [<] [Tab k+3] [Tab k+4] [Tab k+5] [>] [>>] [>|] [X]

[>|] should make the tab row move to the right end:

  [N] [|<] [<<] [<] [Tab n-2] [Tab n-1] [Tab n] [X]

and [|<], [<<], [<] should of couse do the same in the left direction.

Then there is still the tab reordering issue. In this case, just drag and drop,
and when you drag over the [>>], for example, the tab row should keep going "one
page" to the right, until you see the place where you want to drop, and drop it.

I know, I know, this would not be easy to realize... But you *are* all looking
for a challenge, right?
I think we should not have many new buttons to select tabs,
it makes the UI too complicated.
The comment #4 is a simple and working solution.
This patch is for that.
(I have currently 34 tabs of which 10 are visible 
and everything is working just fine.)

Could we use this solution for now and if someone makes something
better then remove this?
Some issues:

1) there's a fixed maximum of 10 tabs. 
   - this isn't going to work. Why 10? Because it works for your screen resolution?
2) you set collapsed by default for new tabs. 
  - this is the wrong way, you should only specify this attribute in case you
need it.
3) this patch only works for new tabs but now when you resize your window.
  - resizing the browser window should not be a problem.
4) this patch isn't flexible for future use.
  - mozilla doesn't currently use the 'maxwidth' and 'minwidth' attributes but
that should change in the near future. After all, what is the point of using
unreadable tab labels and why update a tab label which can't be used/read at
all? Your patch will be in trouble when this change is added to the tree. 
I agree with issue 1 . (10 is just usually working well - 
even with low resolutions.)

Issue 2: the tab is set collapsed because this way
the new tab is really invisible when needed. And if it shouldn't be
collapsed, then this.mTabContainer.updateVisibleTabs() makes
it to show up. These things should not be here, but because tabbrowser does not
use tabbox in a right way, the hacks are needed.

Issue 4: (I don't quite understand what you mean about unreadable tab labels.)
I know this patch might not be flexible enough for future, but
the tabbrowser's code is a bit messed so I believe it really should
be (at least partly) rewritten.

I was trying to make pretty small but still working
fix for this simple and annoying problem but I do understand the critic.
*** Bug 162414 has been marked as a duplicate of this bug. ***
My $0.02 on Mozilla's tabbed UI:

* Tab width should be variable, and should use a width based on the length of
page title, limited to some configurable length (e.g. 30 characters). [currently
a tab's title uses a proportion of the available width, _or_ a width of
approximately 35 characters, whichever is less, meaning that all tabs in a
window have the same width. This commonly results in too space much for pages
with short titles, and truncated titles for pages with longer titles]

     _______   _________________________________   _________
  __/ Short \_/ This is a quite long page title \_/ Short-2 \_____________
 |                                                                        |
 |                                                                        |
 |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|


* Tabs should occur on multiple vertical lines, if necessary. [Precedent with
Opera + IE add-ons. Some even have a choice between a single line of tabs that
can be scrolled, or displaying multiple lines to handle overflow; Having tried
using both methods, using multiple lines to me (and others) is more pleasant to
use and feels like a more powerful interface than a single scrollable line]

* Tabs should include a LED load status. [Currently tabs are either loaded or
loading; Two or three more intermediate steps would be good, sort of like a mini
version of a tab's page load indicator that displays in the status bar. There's
an example of a 3-tier traffic light system for tab status shown in a dialog box
in point 22 of http://multizilla.mozdev.org/features.html ; Around two more
tiers to indicate various states of 'pending' would be ideal]
I suspect that variable width tabs will end up being a lose in most cases. I
reported a bug in Chimera relating to slowdowns with many tabs (bug 156607).
From the commentary on that bug, it appears that this is due to Apple's variable
width code.

Accepted that Apple's code may be sub-optimal, but it suggests to me that it may
not be as easy as it seems at first glance.

The rest makes sense to me, and would probably be relatively cheap.
> Tab width should be variable

That's bug 126611.

> Tabs should include a LED load status. [Currently tabs
> are either loaded or loading;

I think that's sufficient.  Besides, that should be an enhancement request in a
different bug.

> Tabs should occur on multiple vertical lines

That's my personal preference, but I'm more in favour of a simple dropdown list
or scrollbar for now.  It's the simplest to accomplish and can address the
immediate issue of the lack of a non-keyboard method of accessing overflow tabs.
 Further refinement can come later.  I'm worried that a lot of debate here will
simply hinder the progress of *any* solution.
> * Tabs should include a LED load status. [Currently tabs are either loaded or
> loading; Two or three more intermediate steps would be good, sort of like a mini
> version of a tab's page load indicator that displays in the status bar.

See bug #133053
*** Bug 163318 has been marked as a duplicate of this bug. ***
Comment from bug 163318

 +-------+-------+-------+-------+
 | tab 1 | tab 2 | tab 3 | tab 4 |
+-------+-------+-------+-------+
| tab 5 | tab 6 | actual| tab 8 |
+-------+-------+       +-------+
| actual tab content            |

 +-------+-------+-------+-------+
 | tab 5 | tab 6 | tab 7 | tab 8 |
+-------+-------+-------+-------+
| actual| tab 2 | tab 3 | tab 4 |
+-------+-------+       +-------+
| actual tab content            |
Let me just take the previous comment and clarify something.

Whenever the idea of multiple lines of tabs comes up, the one biggest argument
against using it is because people don't like the idea of tabs "jumping" all
over the place.  I think that this is a mistaken idea of what would happen in
such a circumstance because of the way that Microsoft has implemented multiple
lines of tabs in their own interface.  With Microsoft, when you click on a tab,
that tab row suddenly becomes the bottom tab row, and everything does jump
around.  I think that behaviour is awful and have always hated it.  I would not
be impressed if multiple tab rows were adopted by Mozilla and implemented the
same way - but there is no reason for a solution here to incorporate that faulty
behaviour.

Comment 31 again represents the faulty jumping behaviour that seems to be the
biggest complaint against using multiple tab rows.  Here's an example of better,
non-jumping behaviour:

+-------+-------+-------+-------+    +-------+-------+-------+-------+
|   1   | [ 2 ] |   3   |   4   |    |   1   |   2   |   3   |   4   |
+-------+-------+-------+-------+    +-------+-------+-------+-------+
|   5   |   6   |   7   |   8   |    |   5   |   6   | [ 7 ] |   8   |
+-------+-------+-------+-------+    +-------+-------+-------+-------+
|            Content            |    |            Content            |


Tab 2 clicked, content displayed.    Tab 7 clicked, content displayed.

There is no reason why the tab rows have to jump around.  Leave them exactly as
they are and simply change the display portion.  This then makes the tab rows
behave more like buttons on a "control panel", with the content being the
"display screen".
Yes but this way you loose the methaphore of a phisical archive, with sheets
which have a tab on one side... top row tabs wouln't be connected to the page.

Anyway, no problem for me, one will do as does the other ;)
*** Bug 165434 has been marked as a duplicate of this bug. ***
Attached patch Tried arrowscrollbox (obsolete) — — Splinter Review 
2 problems: Default tab doesn't work, and context menu doesn't work :-(
Depends on: 168877
No longer depends on: 168877
QA Contact: sairuh → pmac
*** Bug 179279 has been marked as a duplicate of this bug. ***
*** Bug 180682 has been marked as a duplicate of this bug. ***
I am proposing the idea of tab inheritance.  A second row of tabs should be
opened underneath the existing tab the window was opened from, creating a tree
like layout.  This would prevent so many tabs from being opened, and allow
easier navigation between tabs.


shwag: That has been propsed before (bug #146677) and WONTFIXed.
*** Bug 181691 has been marked as a duplicate of this bug. ***
*** Bug 184964 has been marked as a duplicate of this bug. ***
Blocks: 153016
People!
Please, do something with this bug!
This is MOST irritating thing in such a perfect browser.
(as well as lack of changing tabs order)
At least add scrolling to the next/previous with arrow buttons as it done in
NetCaptor or CrazyBrowser.
PLEASE!

p.s. sorry for such message, but now we already have v 1.3 alpha - and still
nothing :(
Keywords: mozilla1.4
Keywords: nsbeta1
I'd like to add my vote for this to be fixed.

I think having a dropdown on the right-hand-side is an excellent idea. It would
look almost Identical to what you get when you click on the Bookmarks tab.

I don't think scrolling is particulary (sp?) useful as you can't see what your
scrolling anyway (All you see is a small tab with an icon).

I love using tabbed browsing (I deleted my IE shortcuts after one day of using
it). This is the only outstanding UI issue from a perfect tabbing experience.
IMHO.  :)
> I don't think scrolling is particulary (sp?) useful as you can't see
> what your scrolling anyway (All you see is a small tab with an icon).

First of all, I'm going to hope that when this bug is fixed, the maximum number
of tabs before overflow is going to be tweaked.  There should be about half as
many as there are currently.  If this is the case, then scrolling would work
just fine.

Secondly, I don't really care which of the many suggestions already proposed
here gets implemented - so long as *something* gets implemented.  Anything at
all is better than what we have at present - which is just awful for those of
use who frequently get to an overflow situation.
Start lobbing on http://mozdev.org/bugs/show_bug.cgi?id=3042 for a very good
temporary workaround that could appear much sooner :)
Mozgest is a neat workaround for this problem already. (you don't see the
"current tab" but you can switch between tabs that aren't visible)
http://optimoz.mozdev.org/gestures/index.html
I appreciate the sentiment, and another alternative is Piro's tab extensions at
http://white.sakura.ne.jp/~piro/xul/_tabextensions.html, but this bug is
concerned with something that should be native to Mozilla. (Otherwise, this bug
wouldn't be here. <grin>)
*** Bug 195468 has been marked as a duplicate of this bug. ***
Crazy Browser (An MSIE front end for Windows) has an interesting tabbed browsing
feature that stacks tabs on top of each other when the titles get long.
Currently Mozilla has tabs side by side, which can be diffcult to read after
more than eight are used. I read a comment on Slashdot which echoed this gripe.
Crazy Browser has this feature disabled. If Mozilla adopts this feature, we
should follow this course. I also suggest that this feature should be used only
when the user has 12 tabs open.
I think Crazy Browser (MSIE frontend) has the answer we are loking for.
To everybody posting here: Please read through all of the previous comments
before making one of your own with a "new" suggestion.  Odds are, it's already
been suggested.

Also, I believe that there should be NO further debate in this bug.  Any
comments should be for the submission of patches, and technical discussions of
patches.

Speaking of which, what is the status of the patches already submitted?  Do any
of them still function, or has the code suffered from bit-rot by now?  Also, is
the 2nd patch in the list obsoleted by the 3rd?  If so, it should be marked as such.
Whiteboard: [Hixie-P0] → [Hixie-P0] Read all comments here, only post new information.
Whiteboard: [Hixie-P0] Read all comments here, only post new information. → [need info][Hixie-P0] Read all comments here, only post new information.
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Attached image Mozilla-1.3 many tabs — 
I have seen some sort of fix for this in a build around 1.1, where a set of
arrows apeared on the right.

In 1.3 it seems to have disappeared and again, many tabs can't be accessed. 

The above shows a 800x600 screen with about 50 tabs. (I was opening many
messages in a mailing list archive thread...)
I just applied Neil's attachment 98482 [details] [diff] [review] to my 3/27-04 build of Mozilla under XP
and it worked, however there are a couple of issues that would still need to be
resolved with it (in addition to the known problems he mentions in comment 35).

1. I don't like how the scrolling takes place on mouseover rather than click. 
It makes it difficult to control the "horizontal movement" of the tab bar.  It
should be modified so that left and right scrolling only takes place when the
scroll arrow is explicitly clicked on.

2. There are left-most and right-most tab "artifacts" being shown.  In other
words, tabs that are only being partially displayed.  The width of the tab bar,
in consideration with all of the screen elements, including the scroll arrows,
needs to be re-worked so that there are never any such artifacts.  You should
see the new tab button, a left scrollbar, a row of *complete* tabs, a right
scrollbar, and the tab close button.

Point 2 is important for those people, such as myself, who have used
userChrome.css to modify the minimum width of tabs so that those that are shown
are actually usable when overflow occurs.  For example, I now overflow at 10
tabs rather than 40 and I can view a meangingful amount of each tab's title
rather than just the icon.  For anybody who isn't aware, and would find this
useful, here is the code:

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

It at least makes overflow a little less painful.  (If I *must* overflow, at
least I'd like to do so in a way where the tabs I have displayed mean something.)
Attached patch Better arrowscrollbox (obsolete) — — Splinter Review 

        Attachment #98482 -
        Attachment is obsolete: true

    
    

    
  
I applied the patch, but I don't have a build environment so had to do it via
the .jar decompress, patch, recompress method.  I also ended up with some patch
errors on the last two files, so I'm not sure if what I'm seeing is the result
of my own problems or of the patch itself.  (Somebody else applying the patch in
a proper build environment would be useful here.)

So, FWIW:

It looks much better.  Good improvement.  However, some of my criticism from
comment 52 still applies.

1. As soon as I hit overflow, I end up with the left-hand scrollbox on top of a
partial left-most tab, and a right-hand scrollbox on top of a partial right-most
tab.  We shouldn't be seeing any partial tabs.  If a tab can only be partially
shown, then don't show it at all.  Every tab shown should be complete.

2. On overflow, the tab bar should remain positioned all the way to the "left"
(with tab #1 fully in the left-most positition and everything else disappearing
off the right hand of the screen).  The left-hand scrollbox should be greyed out
(disabled), although still shown, since you can't scroll to the left.  As soon
as you scroll to the right, the left-hand scrollbox should become active.  Once
you scroll all the way to the right, the right-hand scrollbox should become
greyed out (disabled).

3. When I hover over a scrollbox it activates.  I *really* don't think it should
do this.  Hovering over a scrollbox should, if it does anything, bring up a
tooltip.  Only when CLICKING on the scrollbar should something happen, and that
should be for the tab bar to move a single tab in the direction of the scrollbox
clicked.  (I click 5 times to move the tab bar 5 tabs in one direction.)

4. This can/should be fixed by addressing my 1st point, but if I've scrolled to
the right, so that the left-most tab is only partially displayed, then start
deleting tabs until the overflow condition no longer applies (and the
scrollboxes are removed) the left-most partial tab is not redrawn to become
fully visible again.

    
    

    
  
> However, some of my criticism from comment 52 still applies.

Make that comment 53. <sigh>

    
    

    
  
Comment on attachment 126909 [details] [diff] [review]
Better arrowscrollbox

jag, am I wasting my time?

        Attachment #126909 -
        Flags: superreview?(jaggernaut)

    
    

    
  
Neil: Don't get me wrong.  Your solution is much better than not having one at
all.  I'd easily be happy to have it checked in and then open another bug to
deal with the relatively minor UI problems.  (Plus, I don't even know if what I
saw yesterday were "real" or not since, as I mentioned, I got patch errors and
may have just been looking at a locally corrupted version.)

Also, I find it extremely discouraging that I'm the only person here to comment
on this.  Has nobody else applied the patch and tested it?

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
I understand this is an enhancement and gets low priority, but we are in 1.6 now
and still haven't gotten a fix for this almost 2-year old thing...

Just one comment: I'd like to have the tabs stay in one row, because I've got a
widescreen LCD and the screen height is somewhat limited. If the decision is to
make them multiple rows, please at least add an option to show single row and
use scroll arrows. Thanks.

    
    

    
  
I don't think that it's so important, because TBE
(http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en) exists, and
workarounds it very nicely; users who would like to have that, can install TBE.

    
    

    
  
> users who would like to have that, can install TBE.

As well as hundreds of other features that aren't part of this bug.  Even if
there were an extension that *only* did tab overflow and not hordes of other
things that others following this bug specifically might not want, this is still
something that should be part of Seamonkey natively.  To have tabs off to the
right that aren't readily/easily accessible (it's not obvious that there are
keyboard accelerators to scroll through them) is, IMO, broken behaviour.  It
would *almost* (but not really - only from a UI perspective) be better if there
were simply a maximum number of tabs so you could always access everything that
was available.

Not to mention the fact that TBE is so unstable that it keeps breaking nightly
builds on a regular basis...

    
    

    
  
(In reply to comment #65)
> users who would like to have that, can install TBE.

Actually I was aware of that. Yet still I'd really like to have this little bug
fixed in the suite, so people don't have to go download and install TBE every
time they upgrade the suite.

I'm also trying to teach some of my relatives who don't know much about
computers to upgrade to Mozilla. They use IE for browsing and Netscape 4.8 for
email. I'd hope after the upgrade they can be relatively virus free when
browsing websites, and get to use a better email client. To let them go here and
there to install extensions is not going to be very intuitive.

    
    

    
  
Just a quick idea then: would it be possible to port just this part of TBE to
Mozilla? Because, if yes, this would be very easy (since code already exists),
and it wouldn't be unstable (since it's just one feature).

    
    

    
  
on comment #66:

there are keyboard accelerators to get around this problem?
What on earth are they? I've been hitting everything I can to select the tab to
the right of the current tab, and can't find how to do it.

    
    

    
  
(In reply to comment #69)
> on comment #66:
> 
> there are keyboard accelerators to get around this problem?
> What on earth are they?

You mean "Ctrl-Tab"?

    
    

    
  
Ah, the keyboard-based workaround:

control-tab to move to the tab to the right, and shift-control-tab to move to
the left. Thanks - that makes my life much easier.

It would be nice, once you've opened up your first off-window tab, to see an
alert dialog explaining that the tab UI will never be fixed because the
developers alrady know the keyboard shortcut the alert tells you about. 

    
    

    
  
Lloyd Wood:
(In reply to comment #71)
> It would be nice, once you've opened up your first off-window tab, to see an
> alert dialog explaining that the tab UI will never be fixed because the
> developers alrady know the keyboard shortcut the alert tells you about. 

Please read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html and keep
yourself from adding such comments in the future.

And then please tell me where anybody said this will never be fixed. 
Or did you only imply this because I politely answered your question, trying to
help you?

Do you consider me a developer? I see: developers are the ones who do not want
to fix bu xy and users are the ones who want it fixed.

What about: "Lloyd, please fix this bug or I'll tell everybody you do not want
this fixed."? 
Please get a rough idea of open source before posting comments. Just as a hint:
if/when somebody decides to fix this, he will do it for free in his spare time.
And surely not because you told him to do so.


Don't get me wrong: this bug also annoys me sometimes (although I rarely have so
many tabs open). But I know that I can't force anybody to fix it.

    
    

    
  
In the continued absence of a real fix after two years, it would be nice,
once you've opened up your first off-window tab, to see an alert dialog
explaining the available keyboard shortcuts for accessing off-window tabs.

It's a lousy partial workaround, but better than nothing.

(vote for this bug to be fixed.)



    
    

    
  
In addition to what comment #55 mentions, Neil's latest patch has more problems,
e.g. with resizing: 
Open _many_ tabs in a narrow window, scroll all the way to the right and then
make the window wider: the new space will not be used for tabs.
Or with closing tabs:
Create many tabs, scroll to the right, context menu on leftmost, partially
visible tab, "Close all other tabs": you will only see that partial tab.
(I think I also got it to displaying no tab at all with more usual steps, but
can't remember how)

I'm not sure if a dropdown would be nicer, because scrolling is a bit confusing
when you do not know which scrolling position you currently are at...

And: displaying parts of tabs (comment #55, 1.) per se does not look like a real
problem to me. I think it makes the solution much easier than forcing only full
tabs to be visible. And with a vertical line on both sides where the tabs
"disappear behind" this could also look logical. 

    
  
Flags: blocking1.7b?

    
    

    
  
not going to block 1.7 for this issue.
Flags: blocking1.7b? → blocking1.7b-

    
    

    
  
I just did a test build for bug 76831 and afterwards recognized I re-used the
tree with Neil's patch for this bug.

Lloyd, Vedran, Darrel and all others:
You can profit from this and download the test build from
http://i08fs1.atis-stud.uni-karlsruhe.de/~s_kunz/mozdev/bug76831.zip
(at least for a few days from now). Please send me a short mail when you do so,
so I get a rough estimate of the bandwidth used. BTW: this is a Windows build
(that other bug is Win only).

I refreshed the tree a few hours ago, so the build you get is a few patches
post-1.7b. That other bug's patch will not affect you as long as you don't set a
certain pref as described in bug 76831. Of course you are free to do so if you
are interested in that bug.

    
    

    
  
FWIW: I'm now using clav's excellent Flowing Tabs extension
(http://forums.mozillazine.org/viewtopic.php?p=546615#546615).  There are some
issues with how things are presented - mostly because of seemingly silly backend
code which I don't understand and which can't be overrridden by the extension
via CSS - but it's essentially a quite workable solution to this problem.  (He
has another extension, Scrollable Tabs, but I don't believe it currently works
with Seamonkey.)

It could be worthwhile for somebody to see what he's done and try to get a
proper patch together for the trunk itself.  (I'm not competent enough to do
that or else I would.)

    
    

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

    
    

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

    
    

    
  


  
This is a very simple solution that has been mentioned in this bug. I think it
would be the fastest, simplest fix for this issue (Without the "X" close boxes
as mentioned as WONTFIX in bug 108938). I think if we were to allow multiple
rows, that would create added complexity for tabbrowser and would probably need
to be a whole new XUL element.

My only suggestion is to not do it exactly like Gnome does it. Pressing the
arrow shouldn't change the selection tab, but simply move the row over one. If
your selected tab will move out of sight, then we'll probably need to take into
consideration that we'll lose the visual association between the tab and the X
(if bug 117077 is fixed). The current tab might need to be anchored on the left
when scrolling in this case because changing tabs as they are scrolled will
slow things down immensely and be unexpected behavior.

Re Comment #8 - Screen resolution and system font size will have to be put into
consideration.

Comment #17 - That will make it harder to make the visual association between
the X and tab, and also the open tab and the tab's frame. Multiple rows for
tabbing seems like something that would also be a lot more work and complexity.
I do see the merits, but that won't be as fast as a fix as left and right
scroll of tabs. Also, left and right scroll of tabs is standard behavior for
tab frames.

    
    

    
  
Brian: 
That's pretty much what Neil's patch in attachment 126909 [details] [diff] [review] does.
However, as I already said in comment #74, that patch has several errors and you
can test it yourself when downloading the test build from comment #76.

    
    

    
  
Agree with Jason's comment #77. FWIW: The FlowTabs XPI is a small (4 Kb),
single-purpose extension, which implements tabs flowing onto multiple rows when
needed. (Link: http://extensionroom.mozdev.org/more-info/flowtabs ). From my
perspective, it works well, and seems a good solution to the basic problem
discussed in this bug regarding what to do when there are lots of tabs. Maybe
something based on this or something like it could be included in the tree?

    
  
Blocks: 161466

    
    

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

    
    

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

    
    

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

    
  
Flags: blocking-aviary1.1?

    
    

    
  
Would just like to note, as more of a user, I'm against multiple tab rows
displayed vertically. They shorten the available space to display the actual
webpage. And yes, I have had and needed 70+ tabs open, and having ~4-5 rows of
tabs intruding on webpage space is not what I want to see (potentially, as
x->inf., this could fill the whole screen). I would much prefer a scroll/next
row button or mini scroll-bar.

If this is not reasonable, please at least include an option in preferences
between a next-row button and vertically displayed rows.


    
  
Whiteboard: [need info][Hixie-P0] Read all comments here, only post new information. → [need info][asaP1][Hixie-P0] Read all comments here, only post new information.

    
    

    
  
(In reply to comment #82)
> Agree with Jason's comment #77. FWIW: The FlowTabs XPI is a small (4 Kb),
> single-purpose extension, which implements tabs flowing onto multiple rows when
> needed. (Link: http://extensionroom.mozdev.org/more-info/flowtabs ). From my
> perspective, it works well, and seems a good solution to the basic problem
> discussed in this bug regarding what to do when there are lots of tabs. Maybe
> something based on this or something like it could be included in the tree?

I tried to install Flowing Tabs in Firefox today but couldn't ("This extension
is not compatible with versions of Firefox later than 0.10" -- or something to
that effect). I also tried Scrollable Tabs but I had to remove it as the remedy
was worse than the ill (tabs were made variable-width with full text, meaning
less tabs were visible; the [x] close tab button became overlaid by the text of
the last visible tab, the advertised scrolling buttons were not there, ...).

OTOH, keyboard hotkeys are a good help (and, IIUC, they don't need any
particular extension to work): Ctrl-Tab "Next tab (round-robin)", Ctrl-Shift-Tab
"Previous tab (round-robin)"; Ctrl-W "Close current tab" etc. It would be nice
to be able to select an arbitrary invisible tab but I can live without it.

FYI, currently I'm using aviary nightlies; my current one is "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050409 Firefox/1.0.3".

    
    

    
  
> I tried to install Flowing Tabs in Firefox today but couldn't ("This extension
> is not compatible with versions of Firefox later than 0.10" -- or something to
> that effect).

The original author hasn't updated it to allow installation on newer versions of
Firefox, but someone else has. Try the link on
http://www.extensionsmirror.nl/index.php?showtopic=232
(I.e. Direct link to repackaged XPI:
 http://www.extensionsmirror.nl/extfirefox/Flowing_Tabs_0.4_rep.xpi
)

> And yes, I have had and needed 70+ tabs open, and having ~4-5 rows of
> tabs intruding on webpage space is not what I want to see (potentially, as
> x->inf., this could fill the whole screen). I would much prefer a scroll/next
> row button or mini scroll-bar.

I've been in the same situation (lots of tabs, on 4 or 5 or 6 rows, eating into
screen real-estate), but for my 2c, I want to see those tabs on different rows,
because that way I can see them all at once, and I often want to toggle between
2 or more specific tabs; If they were all on one long scrollable single row,
then I'd be wasting time scrolling around left and right, searching for the
correct tabs (and as the number of tabs approached infinity, the more annoying
this would get). For me, the annoyance of this is exceeds the annoyance from
lost screen-space.

> If this is not reasonable, please at least include an option in preferences
> between a next-row button and vertically displayed rows.

That's what NetCaptor does (or at least used to do - I haven't used it in ages)
- offers a choice between multiple rows of tabs, and one single line that can
pan left or right. I agree supporting both would be a good solution, but it
(like most Mozilla things) will ultimately come down to what the person who
creates the accepted patch is willing to implement.

    
    

    
  
(In reply to comment #88)
> > I tried to install Flowing Tabs in Firefox today but couldn't ("This extension
> > is not compatible with versions of Firefox later than 0.10" -- or something to
> > that effect).
> 
> The original author hasn't updated it to allow installation on newer versions of
> Firefox, but someone else has. Try the link on
> http://www.extensionsmirror.nl/index.php?showtopic=232
> (I.e. Direct link to repackaged XPI:
>  http://www.extensionsmirror.nl/extfirefox/Flowing_Tabs_0.4_rep.xpi
> )
> 

Thanks for the link.

> > And yes, I have had and needed 70+ tabs open, and having ~4-5 rows of
> > tabs intruding on webpage space is not what I want to see (potentially, as
> > x->inf., this could fill the whole screen). I would much prefer a scroll/next
> > row button or mini scroll-bar.
> 
> I've been in the same situation (lots of tabs, on 4 or 5 or 6 rows, eating into
> screen real-estate), but for my 2c, I want to see those tabs on different rows,
> because that way I can see them all at once, and I often want to toggle between
> 2 or more specific tabs; If they were all on one long scrollable single row,
> then I'd be wasting time scrolling around left and right, searching for the
> correct tabs (and as the number of tabs approached infinity, the more annoying
> this would get). For me, the annoyance of this is exceeds the annoyance from
> lost screen-space.
> 
> > If this is not reasonable, please at least include an option in preferences
> > between a next-row button and vertically displayed rows.
> 
> That's what NetCaptor does (or at least used to do - I haven't used it in ages)
> - offers a choice between multiple rows of tabs, and one single line that can
> pan left or right. I agree supporting both would be a good solution, but it
> (like most Mozilla things) will ultimately come down to what the person who
> creates the accepted patch is willing to implement.

Would it be possible to implement something similar to the following? (I haven't
invented it; the taskbar on my machine works more or less like this):

- By default there is one row of tabs.
- The bar can be resized by mouse (and/or by about:config) to allow several rows
to be visible at the same time.
- Its height will not change spontaneously.
- When there are too many tabs for all of them to be visible, an additional
button [v] at right opens, when clicked, a drop-down list showing at least the
"invisible" tabs.

    
    

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

    
  
Blocks: 128632

    
  
Flags: blocking1.8b4?

    
    

    
  
We should make a decision on this. Ben, Mike, are we gonna try to do anything
here (I personally think that any solutions proposed are worse than the problem
and suggest we do nothing). If we are, time is getting very short. If we're not,
then let's minus this quickly and get on to other things. 
Flags: blocking1.8b4?
Flags: blocking1.8b4+
Flags: blocking-aviary1.1?

    
    

    
  
Now is way too late to make a major UE change.  There's a Flowing Tabs extension
(also a userChrome.css hack) that lets you have multiple rows if so desired. 
Otherwise, lets revisit this early next cycle.
Flags: blocking1.8b4+ → blocking1.8b4-

    
    

    
  
(Just a sidenote that Flowing Tabs are pretty useful, based on my Opera
experience. Saving them (automagically) sucks so hard that it creates vacuum in
20km radius but that's another matter... Bug 159357 )


    
    

    
  
Removing myself from this list.

    
    

    
  
(In reply to comment #92)
...
> Otherwise, lets revisit this early next cycle.

Just wanted to flag this for 2.0 cycle. 
Flags: blocking-aviary2.0?

    
    

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

    
  
Flags: blocking1.8.1?
Component: Tabbed Browser → XP Apps: GUI Features
Flags: blocking1.8b5-
Flags: blocking1.8.1?
Flags: blocking-aviary2.0?
Product: Core → Mozilla Application Suite

    
    

    
  


  
(In reply to comment #53)
> 1. I don't like how the scrolling takes place on mouseover rather than click.

> It makes it difficult to control the "horizontal movement" of the tab bar. 
It
> should be modified so that left and right scrolling only takes place when the

> scroll arrow is explicitly clicked on.
Improving the scrolling speed made this a non-issue for me. 

> 2. There are left-most and right-most tab "artifacts" being shown.  In other
> words, tabs that are only being partially displayed.	<snip>
I'm in favor of showing partial tabs - it makes it more apparent to users that
there are more tabs that aren't currently shown.  My patch shows partial tabs.

(In reply to comment #55)
> tab.	We shouldn't be seeing any partial tabs.  If a tab can only be
partially
> shown, then don't show it at all.  Every tab shown should be complete.
See previous :)

> 2. On overflow, the tab bar should remain positioned all the way to the
"left"
> (with tab #1 fully in the left-most positition and everything else
disappearing
> off the right hand of the screen).
It does, so long as you dont ask it to focus the tab that overflowed.  If I
open tabs in the background, they can appear offscreen.  This is actually a
little annoying sometimes since I can't be sure I successufully middle-clicked
the link.  Personally I'd prefer to get <80px tabs so I can have more visible.

> The left-hand scrollbox should be greyed out
> (disabled), although still shown, since you can't scroll to the left.
It should, but nsIScrollBoxObject doesn't provide any way to actually determine
that :(

> 3. When I hover over a scrollbox it activates.  I *really* don't think it
should
> do this.  Hovering over a scrollbox should, if it does anything, bring up a
> tooltip.  Only when CLICKING on the scrollbar should something happen,<snip>
See above.
 
> 4. This can/should be fixed by addressing my 1st point, but if I've scrolled
to
> the right, so that the left-most tab is only partially displayed, then start
> deleting tabs until the overflow condition no longer applies (and the
> scrollboxes are removed) the left-most partial tab is not redrawn to become
> fully visible again.
Addressed in the patch I just attached.

        Attachment #199696 -
        Flags: superreview?(jag)

        Attachment #199696 -
        Flags: review?(db48x)

    
    

    
  
I'm removing my vote for this bug because as far as I'm concerned, Firefox 1.5
beta with "Tab Mix Plus" extension is an adequate solution. (Allows flowing
tabs, scrolling tabs, or neither; min/max tab width and max no. of flowing-tabs
rows are user-settable in the Options UI; etc.etc.etc.) 

YMMV; see https://addons.mozilla.org/extensions/moreinfo.php?id=1122 and
http://forums.mozillazine.org/viewtopic.php?t=327222

Not (yet?) available for the Mozilla suite, but maybe if someone politely asks
the author, he might either write a Mozilla version, or allow you to do it
yourself (Who knows? If you don't ask, you won't get a "yes" answer).

    
    

    
  
(In reply to comment #97)
> Created an attachment (id=199696) [edit]
> patch (based on previous patches here)

>+.autorepeatbutton-up[orient="vertical"]
>+  {
>+    list-style-image      : url("chrome://global/skin/arrow/arrow-up.gif")
>+  }
>+

Instead of making these kind of css changes in scrollbox.css you should just
incorporate the patch from bug 186856 which does them globally (though you may
still wish to add some cosmetic css like you did here). One problem in
particular with the way you've done it is that I don't think
'.autorepeatbutton-up[orient="vertical"]' will work since the autorepeatbuttons
don't inherit orient.

    
    

    
  
(In reply to comment #99)
> (In reply to comment #97)
> > Created an attachment (id=199696) [edit] [edit]
> > patch (based on previous patches here)
> 
> >+.autorepeatbutton-up[orient="vertical"]
> >+  {
> >+    list-style-image      : url("chrome://global/skin/arrow/arrow-up.gif")
> >+  }
> >+
> 
> Instead of making these kind of css changes in scrollbox.css you should just
> incorporate the patch from bug 186856 which does them globally (though you may
> still wish to add some cosmetic css like you did here). One problem in
> particular with the way you've done it is that I don't think
> '.autorepeatbutton-up[orient="vertical"]' will work since the autorepeatbuttons
> don't inherit orient.


Doh! meant bug 103723 (sorry for bugspam)

    
    

    
  
I've been working on an extension which allows you to choose between all the
main ways of dealing with too many tabs, based on all the suggestions in bug
221684, bug 155325, bug 106927 and bug 139272. I thought I'd do a summary of all
the options for this bug, and have included my observations after about 6 months
of testing all the possibilities.

In no particular order:

1. Arrowscrollbox (aka scroll buttons)
=====================================
When you have too many bookmarks, scroll up/down buttons appear at the top and
bottom of the bookmarks menu. The same component can be used to show left/right
arrows on either side of the tabs, when necessary (the patch to bug 103723 makes
it neater).

Note: this could just be done with 'normal' scroll left/right buttons, but the
effect is the same

PROS: very little screen space used, easy to implement

CONS: anyone with lots of ungrouped bookmarks will attest that it's really
annoying having to wait 60 seconds just to scroll down to that bookmark you
wanted 2/3 of the way down, and just generally quite a hard scrolling system to
use due to the quirky onhover behaviour, fast scrolling making precise selection
hard (though scrolling is also too slow to traverse the set of items), no
indication of how far you've scrolled, etc...

2. Scroll up/down buttons
=========================
Do what the windows taskbar does: A 2-part button on the right hand side of the
tab bar allowing to scroll up or down through the "rows of tabs" (only one row
is ever visible at a time though).

PROS: very little screen space used, easy to implement

CONS: many of the same problems as 1, and not very intuitive as the user expects
to scroll left/right, not up/down

3. Scrollbar (horizontal)
=========================
Apparently this was present and quite popular in TBE. Either way a scrollbar is
a very effective tool for scrolling large numbers of things (unsurprisingly!).
It could either just scroll the tab bar (and you have to then click on the tab
you want etc.), or have it's position directly linked to the tab index.

Note: if there's a way of making scrollbars half their normal height that could
be nice

PROS: Doesn't take up much screen space, easy to implement and easiest to use of
the scrolling mechanisms, especially since scrollbars inherently allow scroll
one, scroll row, and scroll manually.

CONS: The first time they see it users might not be sure what it does, though if
it scrolls as they switch tab it'll soon be obvious.

4. Multiple rows
================
The controversial option - many people want this, many hate it.
For it to be sensible there should be a mechanism for dealing with when more
than, say, 4 rows or 20% of the screen is taken up by this - adjustable by
dragging a splitter (like the windows taskbar does). Then have a vertical
scrollbar, or perhaps vertical scroll buttons (possibly even a dropdown).
Perhaps the best way of doing this would be to only show the inactive rows when
the user hovers over the tab bar for a sufficient period (in this case as many
rows as can fit on the screen should be shown before scrolling).
I also think that while there are multiple rows tab width should remain fixed
(except perhaps on the bottom row), as otherwise tabs wouldn't line up, and
would kept moving around, as well as it being an absolute pain to implement.

Note that if we allow the number of visible rows to be adjusted by dragging a
splitter, we could just set the default to 1, hence allowing users to choose
whether to use multiple rows or not.

PROS: all tabs accessible at once (unless very many are open)

CONS: Where did all my screen space go?, hardest to implement well.

4. Tab menu
===========
A dropdown menu shows all tabs, to enable instant selection. This could be
accessible via an entry in the Go menu, a button somewhere, and/or a keyboard
shortcut. Note that this could be used AS WELL AS one of the options above
(except perhaps multiple rows). The important question is what to do when the
menu is too long for the screen. Either multiple columns (instant access to all
tabs), a vertical scrollbar (unusual but fairly effective UI) or an
arrowscrollbox (standard but hard to use, see 'CONS' for option 1).

I would also suggest that this menu behave like the tab bar, e.g. right-click to
get the tab right-click menu. It may also be nice to switch tabs when the user
just hovers over menuitems in this menu, however low-spec systems might suffer
so that could be a hidden option or extension.

Note: many people have proposed having a "tab overflow menu" launched from a
chevron button (>>), however any sensible tabs implementation will make sure the
currently selected tab is always on screen (except perhaps if the user then
scrolls away), so there would need to be a very clear separation between tabs
before those visible and tabs after those visible. Even so this would be
confusing. The visible tabs probably should be shown differently (e.g. italic)
though, and the active one in particular (e.g. bold).

Note2: Or to really make a difference (and complement 1, 2, 3 or 4) this could
be sorted by last accessed (or created in the case of tabs which have never been
accessed).

PROS: see full(er) tab titles when finding tabs, instant access to all tabs, yet
little to no screen space used, and novices can ignore it.

CONS: erm... slightly slow to get to if in the Go menu?

Personally
==========
IMHO (after implementing and testing all the possibilities), I find that a
horizontal scrollbar underneath the tab bar (3) when tabs overflow is the
easiest to use, as scrollbars are very flexible, and also show where you are in
the collection of tabs; and having a list of all currently open tabs accessible
via a (multi-columned) popup on the Go menu (and keyboard shortcut? like Opera
uses Ctrl-Tab...) is the perfect complement to this when instant access to a
particular tab is needed.

I also found using an arrowscrollbox to be the least effective approach (for the
reasons explained above) and would not recommend it.

Notes
=====
If any of the scrolling solutions (1st, 2nd, or 3rd when not all tabs are shown)
are used the display should automatically scroll to keep the active tab onscreen
(though the user can still scroll away if applicable).

In most cases, the new functionality should only be visible once tabs start
overflowing.

Whatever the solution (except just 4. tab menu) it may make sense to increase
the default minimum tab width.

I have programmed almost everything above in extension form (though for
Firefox), so would happily convert one of the solutions into a patch.

Apologies for the long post!

    
    

    
  
Comment on attachment 199696 [details] [diff] [review]
patch (based on previous patches here)

There is so much to read in this bug, but looking at the patch I see a few things that seem wrong:

* Why change autorepeatbutton-up to be the left-button? Same for autorepeatbutton-down to right.

* <arrowscrollbox> should not be hardcoded to scroll 20px in all cases. Note that this widget is used all over the place; inside menupopups etc.

It might be easier to re-do a patch for this bug once bug 222274 is fixed. If I could I'd give this review-.

    
    

    
  
Would it be hard to make the scrollbar appear only on tabbar overflow? This way, as long as the number of tabs is kept low, no screen estate is wasted (and no scroll mechanism needed).

One more idea, not sure if better but possible for considering, somewhat similar to scrollbar - "panning". Grab the tab bar (any tab or empty space) and drag it horizontally, whole tab bar scrolls the way you pan the image by dragging it in AcroRead.
Pros: No screen real estate used at all. Easy and comfortable for number of tabs not exceeding twice-thrice the standard capacity.
Cons: Not very intuitive (no hints that it is there whatsoever), with lots and lots of tabs it will require repeating "grab and drag" multiple times.

    
    

    
  
(In reply to comment #103)
[...]
> One more idea, not sure if better but possible for considering, somewhat
> similar to scrollbar - "panning". Grab the tab bar (any tab or empty space) and
> drag it horizontally, whole tab bar scrolls the way you pan the image by
> dragging it in AcroRead.
[...]
> Cons: Not very intuitive (no hints that it is there whatsoever), with lots and
> lots of tabs it will require repeating "grab and drag" multiple times.

Also, it would interfere (especially once the tab bar is full) with tab reordering by drag and drop.

-----
(In reply to comment #101)

ATM (and just FYI) I'm seeing two Firefox extensions which make this bug much less painful:
- Tab Mix Plus http://tmp.garyr.net/ or (for the most recent version) http://tmp.garyr.net/alpha/ -- its options include:
    When tabs don't fit, make it:
       [ Scrollable with buttons     |v]
       | Scrollable without buttons  |
       | Multi-row                   |
    Max number of rows to display: [ 3    ]
    Tab width (22~1000): [ 30   ] to [ 250  ]
- Tabs menu http://endbracket.net/michael/projects/firefox/
adds a "menu" of all tabs: Tab&s between &Tools and &Help on the main menu bar

These two might IMHO serve as a "source of inspiration" for anyone wanting to fix the bug.

Note: It has long been debated above what is the "best" solution. TM+ shows that the best solution may be to let the user choose between several possibilities; TabMenu shows that solutions need not be exclusive.

    
    

    
  
(In reply to comment #103)
> Would it be hard to make the scrollbar appear only on tabbar overflow?
no, that's what I was suggesting.

> "panning". Grab the tab bar (any tab or empty space) and drag it horizontally,
> whole tab bar scrolls the way you pan the image by dragging it in AcroRead.
ugh, no! ;)

(In reply to comment #104)
> TM+ shows that the best solution may be to let the user choose between several
> possibilities; TabMenu shows that solutions need not be exclusive.
The devs have made it clear that they will only add one possibility and do not want more preferences (certainly not visible ones). Though I agree that having a menu of tabs as well a simple fix could be very useful.

    
    

    
  
(In reply to comment #105)
[...]
> (In reply to comment #104)
> > TM+ shows that the best solution may be to let the user choose between several
> > possibilities; TabMenu shows that solutions need not be exclusive.
> The devs have made it clear that they will only add one possibility and do not
> want more preferences (certainly not visible ones). Though I agree that having
> a menu of tabs as well a simple fix could be very useful.

Well, in that case the fix, whatever it is, is likely to be "not good enough for me" (I don't know about the next guy but I guess I'm not alone), so I'll keep both TabMixPlus and TabMenu -- and also NightlyTesterTools so I can easily bump the extensions' maxVersion in case their authors don't do so in a timely fashion. FWIW to me, you could as well mark this bug WONTFIX and leave the fix to extension makers (who have already fixed it, both more thoroughly and more flexibly -- more "user-friendlily" if that's a word -- than "the devs" seem disposed to). ;-) Have a nice day!

    
    

    
  
(In reply to comment #105)
> (In reply to comment #103)
> > Would it be hard to make the scrollbar appear only on tabbar overflow?
> no, that's what I was suggesting.
> 
> > "panning". Grab the tab bar (any tab or empty space) and drag it horizontally,
> > whole tab bar scrolls the way you pan the image by dragging it in AcroRead.
> ugh, no! ;)
> 
> (In reply to comment #104)
> > TM+ shows that the best solution may be to let the user choose between several
> > possibilities; TabMenu shows that solutions need not be exclusive.
> The devs have made it clear that they will only add one possibility and do not
> want more preferences (certainly not visible ones). Though I agree that having
> a menu of tabs as well a simple fix could be very useful.
> 

This extension seems to work also:
http://timothyhumphrey.name/firefox/

    
    

    
  
Whatever is implemented should be able to work properly with the new tab drag and drop (bug 105885).  The Flowing Tabs extension doesn't - you can only drag and drop to the top row of tabs.  Not a big deal, really, but anything built-in to the browser should fully support this.

    
    

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

    
    

    
  
I think that the best idea - multistring tabs.
 _________  _________  _________
/ qweqweq \/asdasdad \/asdasddd \
 _________  _________  _________
/ sdsdfsdf\/ dfdsfsd \/ sdfsdf  \

    
    

    
  
(In reply to comment #108)
> Whatever is implemented should be able to work properly with the new tab drag
> and drop (bug 105885).  The Flowing Tabs extension doesn't - you can only drag
> and drop to the top row of tabs.  Not a big deal, really, but anything built-in
> to the browser should fully support this.
> 

IIUC, the drag-drop mechanism implemented by the Tab Mix Plus extension works on all tab rows when the user elects to have overflowing tabs flow to parallel tab rows. I suggest you take a look at it.

    
    

    
  
Comment on attachment 199696 [details] [diff] [review]
patch (based on previous patches here)

no, a scrollbox is not the way to go.

        Attachment #199696 -
        Flags: review?(db48x) → review-

    
    

    
  
It seems obvious to me that this is a critical update for many tab users in Firefox.  This bug has been open for nearly four years and no agreement has been reached.  Is anyone working on anything new (since 2005-10-15) ?  Even at 1280x1024, I run out of room for tabs at 40 on my display.  As mentioned previously, I don't care what method is used to make it work, just as long a solution comes soon.  The current implementation is broken.  Since the details of this bug demonstrate that enough and there are already 50 votes, I'm raising the severity on this from Enhancement to Normal as documented in the severity descriptions.  This is because no easy work-around is readily available (users can't see how many tabs are open or which tabs are open beyond the 40th in my case).

IMNSHO, this should be a blocker for the next release.  Also, how is it that Bug 161466 was able to be resolved without this being fixed first?  It seems to me that the block list doesn't mean anything to the developers at this point.
Severity: enhancement → normal

    
    

    
  
(In reply to comment #113)
> It seems obvious to me that this is a critical update for many tab users in
> Firefox.

This bug is about Seamonkey, not Firefox (hence why it says Mozilla Application Suite at the top).
The Firefox bug is bug 221684, and is being worked on (it is indeed targetted for Firefox 2 beta1 and is blocking Firefox 2).

I expect someone will port the Firefox solution to Seamonkey not long after it is fixed though.

> This bug has been open for nearly four years and no agreement has
> been reached.

Unfortunately complaining on a bug only wastes developers time, those who get sent your comments already know about the bug.

> Also, how is it that Bug 161466 was able to be resolved without this being
> fixed first?  It seems to me that the block list doesn't mean anything to
> the developers at this point.

Blocking is more of a suggestion than a requirement ;)

    
    

    
  
Just an FYI for reference. This works pretty well in Firefox. I don't know about in Seamonkey, but it may lend a clue or two for usefulness:

LastTab (https://addons.mozilla.org/firefox/112/)

    
    

    
  
(In reply to comment #114)
Bug 311696 is listed as a duplicate of this one.  Bug 311696 >is< for Firefox.
It would be really nice if when trying to find a fix for a problem --- or any info for that matter, if there could be less confusion and more consistancy.

Personally, I am spending a couple of hours trying to find out why my scroll
wheel on my mouse no longer works on the tab bar in Firefox and I think I am getting cranky.  (1st it didn't work after the last upgrade install and then I added the Tab Catalog extension,  which states itab scrolling is a feature, and it worked for awhile and then stopped again.) There  is no 2nd tab bar.  I cannot access tabs past 16, I have to close something to get to it or open a new window.  I know there used to be a 2nd tab bar when the 1st got full in Firefox  and in Foxfire or Opera there was a view open tabs which gave you list.  I would just like to be able to get to the rest of the tabs.  If anyone can help you can email me at 2liz@cox.net

Liz 


> (In reply to comment #113)
> > It seems obvious to me that this is a critical update for many tab users in
> > Firefox.
> 
> This bug is about Seamonkey, not Firefox (hence why it says Mozilla Application
> Suite at the top).
> The Firefox bug is bug 221684, and is being worked on (it is indeed targetted
> for Firefox 2 beta1 and is blocking Firefox 2).
> 
> I expect someone will port the Firefox solution to Seamonkey not long after it
> is fixed though.
> 
> > This bug has been open for nearly four years and no agreement has
> > been reached.
> 
> Unfortunately complaining on a bug only wastes developers time, those who get
> sent your comments already know about the bug.
> 
> > Also, how is it that Bug 161466 was able to be resolved without this being
> > fixed first?  It seems to me that the block list doesn't mean anything to
> > the developers at this point.
> 
> Blocking is more of a suggestion than a requirement ;)
> 



    
    

    
  
(In reply to comment #116)
[...]
> There  is no 2nd tab bar.  I
> cannot access tabs past 16, I have to close something to get to it or open a
> new window.  I know there used to be a 2nd tab bar when the 1st got full in
> Firefox  and in Foxfire or Opera there was a view open tabs which gave you
> list.  I would just like to be able to get to the rest of the tabs.  If anyone
> can help you can email me at 2liz@cox.net
> 
> Liz 
[...]

The 2nd (3rd, etc.) tab bar is a function of some extensions such as Tab Mix Plus. Rather than closing tabs, you can go from tab to tab (including hidden tabs) by means of keyboard shortcuts such as Ctrl-PgUp/Ctrl-PgDn or (but not in kde) Ctrl-Tab/Ctrl-Shft-Tab.

    
  
Summary: Very many TABs UI not fully developed → Very-many-tabs UI is not fully developed

    
    

    
  
(In reply to comment #104)
...
> - Tabs menu http://endbracket.net/michael/projects/firefox/
> adds a "menu" of all tabs: Tab&s between &Tools and &Help on the main menu bar
> 
> These two might IMHO serve as a "source of inspiration" for anyone wanting to
> fix the bug.

The url is now: http://mikelward.com/software/firefox/tabs-menu

It works here as far as adding the "Tabs" menu item, but it doesn't change the fact that tabs are otherwise hidden. For example, I'll middle click a bunch of links for my bugzilla mail, and then middle click the bug link. That tab and icon will change, but not as far as I can tell if it is out of bounds. Thanks, and I hope this helps.

    
    

    
  
I just upgraded to Firefox 3.0b2 and am encountering the same issue.  The problem occurs when I have searched in the page and have more tabs than the window can hold.  I'll submit a screenshot so you can see.

If I close the find tab at the bottom the right tab scroll button will reappear.

    
    

    
  
This was also occuring in previous version of Firefox 3 (Gran Paradisio) but I can't remember how far back.  I think I started using back in Alpha 6 or 7 but I can't say for sure that the issue was occuring back then.

    
    

    
  
It appears to only start to happen at a specific width.  At 665 window width (including the blue window sides) the controls on the side are completely gone.  The controls take up 60 pixels in width so at exactly 725 pixels wide the controls are completely visible.

    
    

    
  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050501 SeaMonkey/2.0a1pre

(In reply to comment #122)
> It appears to only start to happen at a specific width.  At 665 window width
> (including the blue window sides) the controls on the side are completely gone.
>  The controls take up 60 pixels in width so at exactly 725 pixels wide the
> controls are completely visible.
> 

Here I can shrink the window, and all controls (scrollbars, etc.) are fully visible as long as there is room in the toolbars for shrinking. When the Location bar has shrunk to an icon with no room for text, the scrollbars move out of sight together with the throbber. Then if I collapse the navigation toolbar by clicking its grippy, the scrollbars come back, so the criterion seems to be "the widest unshrinkable toolbar currently displayed".

However, disappearance of the scrollbars has nothing to do with very-many-tabs UI. Thanks to userChrome.css, I always see all my tabs, on two or more rows if necessary. Jayden, you may want to file a separate bug for this.

    
    

    
  
Jason B, you sent me a private email to which I replied (twice) but my reply emails got blocked by SPF. Do you have another email addy which doesn't use that kind of blocking?

Sorry for the bugspam, guys.

    
    

    
  
I haven't seen the bug I found since I believe FireFox 3.0 beta 4 but it is definitely not happening anymore in beta 5.

    
    

    
  
"it is definitely not happening anymore in beta 5"

As stated several times now, this is a Seamonkey specific bug - so Firefox has no bearing here (except in terms of any possible port). :)

I'd actually replied to Tony's comment 125 privately to ask what userChrome.css entry he was using to allow for multiple rows of tabs - as I hadn't heard of doing that before.  It occurred to me after that that the question, and answer, does have a direct bearing on this bug (at least as a workaround until things can be resolved natively) - so I'll just ask it here.

Also, FWIW, the FlowingTabs extension that I mentioned back in comment 77 doesn't work with Seamonkey pre2.0.

    
    

    
  
(In reply to comment #128)
> "it is definitely not happening anymore in beta 5"
> 
> As stated several times now, this is a Seamonkey specific bug - so Firefox has
> no bearing here (except in terms of any possible port). :)
> 
> I'd actually replied to Tony's comment 125 privately to ask what userChrome.css
> entry he was using to allow for multiple rows of tabs - as I hadn't heard of
> doing that before.  It occurred to me after that that the question, and answer,
> does have a direct bearing on this bug (at least as a workaround until things
> can be resolved natively) - so I'll just ask it here.
> 
> Also, FWIW, the FlowingTabs extension that I mentioned back in comment 77
> doesn't work with Seamonkey pre2.0.
> 

Some software block prevented my replies from reaching you, but my full SeaMonkey 2.0a1pre userChrome.css (including "flowing tabs" rules, but also parts not relevant here and even a few rules that don't work) is now at http://users.skynet.be/antoine.mechelynck/other/userChrome-seamonkey.css

    
    

    
  
Thanks for the userChrome.css example!  I've taken it, identified the relevant pieces, and simplified the entries.  Here is the minimum required to get multi-row tab overflow to work (the rest is just appearance tweaks):

---
tabs>stack>vbox>hbox>hbox
 {
  display: block !important;
  overflow: visible !important;
 }

tabs>tab
 {
  width: 170px;
 }
---

It appears as if the overflow method requires a static width for the tabs.  (You can't have them start off big and then get smaller to a minimum size and then overflow.)  If you don't specify a width, it gets set to something very small.  The only reason I picked "170px" for mine is that's what made my own tabs both readable and allowed as many as possible to fit on the tab bar without whitespace between the right-most tab and the close button - if anybody else wants to use this, they should experiment for themselves.

    
    

    
  
With "width:auto; min-width:16px; max-width:1000px" the width gets set to about 25px and indeed seems fixed, which I found weird but set it aside for the time being. Maybe there's something I missed to make them elastic. Thanks for the thumbs-up anyway. I suppose a fixed width of 16px is good enough for me.

    
    

    
  
"With "width:auto; min-width:16px; max-width:1000px" the width gets set to about
25px and indeed seems fixed"

I believe that both auto and max-width are being ignored.  Since the min-width is greater than the default very small width, it's using that.

Anyway - back to the actual bug now. :)

    
    

    
  
Now I'm spamming myself, but if you do want to use multiple tab rows (and that, on it's own, is not the answer to this bug since it doesn't allow for an unlimited number of tabs since the screen space is finite) here's a tweak that will "pin" the open and close tab buttons where they are - preventing them from "floating" up and down as the number of rows changes:

.tabs-newbutton {top: 0px !important}
.tabs-closebutton-box {top: 0px !important}

    
  
Component: XP Apps: GUI Features → UI Design
QA Contact: pmac
Assignee: jag → nobody
QA Contact: ui-design

    
    

    
  
Note: The CSS fix I gave in comment 133 for pinning the open and close tab buttons to the top no longer works in the latest trunk (2.1a1pre) builds.  It does work in the 2.0 branch builds though.  Also tweaking the summary here for better search results (it always take me a bit of time to locate).
Alias: taboverflow
Summary: Very-many-tabs UI is not fully developed → Very many tabs overflow UI is not fully developed

    
  
No longer blocks: 484968
Depends on: 484968

    
    

    
  
Fixed in bug 484968.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 126909 [details] [diff] [review]
Better arrowscrollbox

obsolete sr?

        Attachment #126909 -
        Attachment is obsolete: true

        Attachment #126909 -
        Flags: superreview?(jag-mozilla)

    
    

    
  
Comment on attachment 199696 [details] [diff] [review]
patch (based on previous patches here)

obsolete sr?

        Attachment #199696 -
        Flags: superreview?(jag-mozilla)

    
    

    
  
(In reply to Philip Chee from comment #139)




Comment on attachment 199696 [details] [diff] [review]

patch (based on previous patches here)


obsolete sr?




Was this an additional patch? Should a new bug be done to add this function?


Flags: needinfo?(philip.chee)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: