Closed Bug 221684 (tab-overflow) Opened 21 years ago Closed 18 years ago

When opening too many tabs you can't move to them with the mouse ("X" button and tabs overlap)

Categories

(Firefox :: Tabbed Browser, defect, P1)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 2 beta1

People

(Reporter: daniel, Assigned: moco)

References

Details

(Keywords: verified1.8.1, Whiteboard: SWAG: 1d 181b1+)

Attachments

(5 files)

Screenshot of bug
2.29 KB, image/png
Details
full-window screenshot (929x741 pix)
108.17 KB, image/png
Details
Solution(s)
30.12 KB, image/png
Details
File to re-create tab browsing bug
7.63 KB, text/html
Details
Idea for graphic design of the final solution
497 bytes, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; es-AR; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; es-AR; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

When you open more of 25 tabs, the next to 25 isn't show in the firebird, and
you can't move to it (for example goto tab 28)
I'm using 800x600 resolution

Reproducible: Always

Steps to Reproduce:
1.Open more of 25 pages in tabs
2.try to goto 28
3.



Expected Results:  
i'm think that the solution will be put an arrow button for scroll in the tabs

my resolution is 800x600
There is the mozilla bug 155325
Confirming on 2003-10-08 build on WinXP. Here the limit is 37 tabs with a
1024x768 resolution.
Assignee: blake → hyatt
Status: UNCONFIRMED → NEW
Component: General → Toolbars
Ever confirmed: true
QA Contact: bugzilla
Summary: more of 25tabs (windows) → When opening too many tabs you can't move to them with the mouse
Same problem in Linux. Konq solves this with a dual left-right icon at the right
end of the tab bar near to where we put the close button (Konq's close button is
a regular toolbar icon like the open tab button).
OS: Windows 2000 → All
would a fix for <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=155325">bug
155325</a> fix this ?
Flags: blocking0.9?
Does this really block 0.9? Is there really a need to have umpteen jillion tabs
open in a single window? While I appreciate that some of us like to have a large
number of tabs open, IMVHO the majority of tabbed browsing users will only have
at most maybe eight tabs open at once. In my personal experience I have never
had more than four or five tabs open, with a maximum of seven or eight on some
occassions.

Something should definitely be developed by 1.0 - but by 0.9?
Bradley, you may very well be correct, but i was attempting to draw attention to
it nice and early so it actually gets done.
*** Bug 237454 has been marked as a duplicate of this bug. ***
Not imminent for 0.9
Smaller bugs like this one should only be set to blocking? status, if a working
patch is supplied.
Flags: blocking0.9? → blocking0.9-
What about a working extension?
*** Bug 249051 has been marked as a duplicate of this bug. ***
*** Bug 251978 has been marked as a duplicate of this bug. ***
I've just tested and confirmed it with Firefox 0.9 and 0.9.2 on windows 98
800x600, and i'd like to add that the UI gets a little broken too.

I can open 25 tabs on 800x600 and tab 26 gets drawn over the "close tab" button
(the orange X), button which retains functionality. (still closes active tab). 
The tab drawn over this button is no longer accessible, the button takes
precedence. 

While having exactly 26 tabs open, tab 26 over the "Close tab" button, being the
active tab, if I load a page in this one, the rotating circle icon (that says
Firefox is loading the page) is drawn on over the "close tab" button too,
instead of it's placement on the right side of the menubar. 

There's the FlowTabs XPI available. When there are many tabs, it creates
multiple lines of tabs. It's not the best solution, but it's a solution, and an
available one.
Attached image Screenshot of bug — 

    
    

    
  
(In reply to comment #5)
> Something should definitely be developed by 1.0 - but by 0.9?

I agree (about getting this fixed in 1.0) though I've got a feeling it might be
denied as the patch would be non-trivial.  I'd disagree with the idea that
fixing this bug is something that should be done by an extension.  In my opinion
it should not be necessary to install an extension to compensate for a bug in
the core functionality.
Flags: blocking-aviary1.0?

    
    

    
  
Not a release blocker. Request blocking-status if a patch is ready.
Flags: blocking-aviary1.0? → blocking-aviary1.0-

    
    

    
  
I second this bug. Not "urgent" just a problem for nutter with many tabs open.
There is always room for perfection, we have been below version 1.0 for a long
time, and I assume that the mozilla team represents perfection as Firefox 1.0

    
    

    
  
(In reply to comment #0)
Yes, it would be great if something would be developed here. A simple Scrollbar
like in the TBE would be really fine. But the TBE are so buggy, that they are
not usable for me. IMO its a Core-feature, that open Tabs are visible (with a
bit of scrolling), doesnt matter how many people have so much tabs open. Please
do something. Or even if somebody do an Extension with a scrollbar, but the
Extensions available are more or less not the right thing.

Thanks in advance,

Jones

    
    

    
  
Expanding the summary to make this bug easier to find.

Prog.
Summary: When opening too many tabs you can't move to them with the mouse → When opening too many tabs you can't move to them with the mouse ("X" button and tabs overlap)

    
    

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

    
    

    
  
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20040927 Firefox/0.10

Default theme and resolution 1280*1024

I think this bug is a regression from when the Close Tab Button was added.

    
    

    
  
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913
Firefox/0.10.1

Same problem in OSX
Though if 'x' button or tab works depends on mouse location. 
Safari solves this problem with a dropdown of undisplayable tabs.

    
    

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

    
    

    
  
I'm a consultant having to admin and develop on websphere portal server and also
on .NET. Therefore i have to search for information many times so that i'm using
many tabs. Also i have to do with crossbrowser functionality, so that i'm using
IE, NetCaptor, Mozilla, Opera, Firefox and Netscape Browsers. The best tabbed
browsing is working on NetCaptor - there you get arrow-buttons if the tabs can't
be rendered anymore - so you can see the content of the tabs everytime. It would
be nice to have tabbed browsing in firefox working this way - scrollbars would
also be a good idea.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Not having found this bug, I tried to file a duplicate this morning but I can't
find it back. I suppose that it "happily" got lost in the Bugzilla maintenance.

On my 1024x768 screen only the first 31 tabs (and a very small part of the 32nd)
are visible.

I was suggesting to implement one or more (hopefully all) of the following:

-- Menus and keyboard shortcuts for "Previous tab" and "Next tab";
-- List of currently open tabs (possibly grouped by window) to allow selection
by clicking even if hidden (in the Go menu?);
-- If opening a tab overflows the screen width, create an additional row of tabs;
-- Allow resizing of the tab bar (increase its minimum height) by dragging its
lower border, like the Window taskbar can be resized by dragging its top border.

After a quick glance through other posts, I notice other people have mentioned
other good possibilities:
-- Add excess tabs to a drop-down list (as in some toolbars of the Windows
taskbar and, IIRC, the Mozilla "Personal Bookmarks" toolbar item);
-- If there are too many tabs, add [<] and [>] buttons on both ends of the
tabbar to rotate it.

IMHO, most of these solutions are compatible with each other.

-- About the utility of fixing this bug: certainly most people use only a
limited number of tabs, but that doesn't describe all people in all
circumstances; and the more tabs open, the nastier the problem. In browsing a
vast site ( http://www.deviantart.com/ ) where each page has a large number of
links to ther pages of the same site, I tried to "save my place" by means of the
Duplicate Tab extension, to allow browsing the site in more-or-less tree-like
fashion. I had more than 50 tabs when it became impractical due to overuse of
actual and virtual memory.

-- Workaround (it's not a pretty one): Using the "Duplicate tab" extension: the
following procedure will move all tabs left by one space round-robin:
1. Click right on first (leftmost) tab. A drop-down menu appears.
2. Duplicate tab -> To new tab.
3. Click right again on leftmost tab.
4. In the drop-down menu, select "Close tab".

-- Another (imperfect) workaround (using the mini-T extension): Use several
windows. With mini-T, dragging a tab from one window's tabbar to another's will
copy (not move) it. (Unlike the previous method, here the back/forward history
does not carry over.) Then delete the original tab to complete the "move" and
"unhide" an additional tab from under the "Close tab" button.

FF= Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0

OS=
Système d'exploitation	Microsoft Windows XP Édition familiale
Version	5.1.2600 Service Pack 2 Nu 2600
Éditeur	Microsoft Corporation

I see this bug is in category Firefox/Toolbars. This morning (by my clock,
GMT+1) I used Browser/Tabbed browser but the category "Browser" seems to have
disappeared in the next quarter-hour.

Best regards,
Tony.

    
    

    
  
As said in comment #1 , is think this should be marked as dupe of bug 155325
(core bug).



    
  
Assignee: hyatt → bugs
Component: Toolbars → Tabbed Browser
QA Contact: bugzilla → firefox.tabbed-browser

    
    

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

    
    

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

    
    

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

    
    

    
  
Every single file touched by the last patch in bug 155325 is forked in Firefox:
it's not a dup, though we could port a fix from there (or, Seamonkey and Firefox
could decide on completely different UI).

    
    

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

    
    

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

    
    

    
  
Re: Comment #29 by Tony:

The best work-around I have found is to use ctrl-tab and ctrl-shift-tab to cycle
through the tabs in a window (I believe this is built into Firefox, and
independent of any extensions).

The extension workaround that works for me is Tab Mix (currently 0.1.5
Homepage: http://hemiolapei.free.fr/divers/tabmix/tabmix.html.en
Via extension mirror: http://www.extensionsmirror.nl/index.php?showtopic=2291
This allows cycling through the tabs, but also seeing each "row" of tabs as you
switch into it. It's also free from the many problems with TBE.



    
    

    
  
And, er, sorry I forgot to remove all the CC's :)

    
    

    
  
(In reply to comment #38)
> And, er, sorry I forgot to remove all the CC's :)

????????????????????????????????

Is this an April Fool's joke or what?

If I add myself back, will you remove me again? And why??????????????????

    
    

    
  
Re: Comment 39:

Beg pardon all, I *thought* I was removing the CC's for my comment alone (saw no
point in emailing everyone with the ctrl-tab shortcut). Adding back in previous
CC's, and looking for bugzilla faq. Again, apologies.

    
    

    
  
(In reply to comment #37)
> Re: Comment #29 by Tony:
> 
> The best work-around I have found is to use ctrl-tab and ctrl-shift-tab to cycle
> through the tabs in a window (I believe this is built into Firefox, and
> independent of any extensions).

Yes, me too I think this is a good workaround. Of course it doesn't allow to
select an arbitrary invisible tab other than by cycling through all intervening
ones, but I can live without that.

> 
> The extension workaround that works for me is Tab Mix (currently 0.1.5
> Homepage: http://hemiolapei.free.fr/divers/tabmix/tabmix.html.en
> Via extension mirror: http://www.extensionsmirror.nl/index.php?showtopic=2291
> This allows cycling through the tabs, but also seeing each "row" of tabs as you
> switch into it. It's also free from the many problems with TBE.
> 
> 

I looked at that extension but had qualms about installing it since it seems it
means I would have had to first uninstall several tab-related extensions with
which I am comfortable (Tabbrowser Preferences, miniT+, Duplicate Tabs; not sure
about Session Saver). The description mentioned Flowing Tabs and Scrollable Tabs
which seemed promising, BUT: (a) Flowing Tabs would not install because my
version of Firefox is later than 0.10 (sic); and (b) Scrollable Tabs did install
but the remedy was worse than the ill: tabs became variable width with full text
(meaning less tabs were visible), the [x] close tab button was overlaid by the
text for the rightmost visible tab, the advertised tab scrolling buttons were
not there, etc.

Best regards,
Tony.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
40th tab is lost
Screen resolution is 1280x1024

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3

    
    

    
  
I've recently begun using the minimal extension
[url=http://www.extensionsmirror.nl/index.php?showtopic=1468]SwiftTabs 0.3[/url]
as remedy for hidden tabs.  This extension allows the user to simply scroll tabs
using the assigned shortcut.  I wonder when the Mozilla Team is going to fix
this bug...

    
    

    
  
(In reply to comment #48)
> I've recently begun using the minimal extension
> [url=http://www.extensionsmirror.nl/index.php?showtopic=1468]SwiftTabs 0.3[/url]
> as remedy for hidden tabs.  This extension allows the user to simply scroll tabs
> using the assigned shortcut.  I wonder when the Mozilla Team is going to fix
> this bug...

I wonder too. However IIUC that extension simply allows you to reassign to keys
of your choice the already-existing functions of Ctrl-Tab (select next tab),
Ctrl-Shift-Tab (select previous tab) and Ctrl-W (close current tab).

I'm using the Flowing Tabs extension, also from The Extensions Mirror, which
allows seeing all tabs at the expense of some screen real estate (when there are
too many to fit on a single row, a second horizontal row is begun, etc.). IMHO a
userChrome.css setting is necessary to keep that encroachment on screen space
within more or less "reasonable" limits. I use the following, which gives me 19
tabs per row on a 1024x768 screen, and lets me see the favicon plus the first
character of the tab title. Of course, YMMV.
/*
 * For use with the Flowing Tabs extension: set min/max width of tabs.
 * In Flowing Tabs, tabs are fixed-size so we set min & max to the same value.
 *
 * (thanks Sboulema)
 */
tabbrowser tab {
  min-width: 50px !important;
  max-width: 50px !important;
}

Best regards,
Tony.

    
    

    
  
1.0 came and went ...

and FlowTabs 0.4 (the latest) does not work on FF 1.0.3


    
    

    
  
(In reply to comment #50)
> 1.0 came and went ...
> 
> and FlowTabs 0.4 (the latest) does not work on FF 1.0.3
> 

I have a Flowing Tabs 0.4 which works flawlessly with Fx 1.0.3 or even 1.0.4; I
downloaded it from The Extensions Mirror http://www.extensionsmirror.nl/ -- in
this case, the page for that particular extension is at
http://www.extensionsmirror.nl/index.php?showtopic=232


Best regards,
Tony.

    
    

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

    
    

    
  


  
I believe the problem I'm having is more of the same as this bug...but maybe
with a new twist.  Instead of the overlapping 'X' described by this bug, all of
the controls (including the 'X') normally at the right-hand side of the window
are beyond the right-hand edge.  I've never noticed this problem before; in
fact I've been using this same window (with just as many tabs) for several days
without a problem.  The problem started this morning, after I logged in over
VNC.  (I have been doing that for quite a while, so it's not related to the
problem.)  What's really interesting to me is that I only had eight tabs open,
and my screen resolution is 1280x1024.	With the window maximized, everything
looks fine.  When I 'restore' the window, the controls that belong at the
right-hand side of the window are so far to the right that they can't be used. 
If I manually expand the width, it reaches a point where everything appears
normal.  If I manually decrease the width, the problem reappears.

Another window that had been open - with many more tabs - demonstrates the same
problem (no 'X'), but at a much narrower width.  Any new windows I create will
demonstrate the overlapping 'X' problem as well as the disappearing controls,
but again, at much narrower widths.

I have no idea how to reproduce this particular manifestation of the problem. 
In fact, I'm confident that the problem will disappear when I close the
windows, and after that I'll never witness it again.  That said, if there's
anything I can do to dig up more information before I close the windows (later
tonight, before a hardware upgrade), let me know.

    
    

    
  
This is still true with the latest snapshot. If you open up a lot of tabs
(40ish) there is no way to get to those that flow past the red X close button. 

I really hope this is fixed in 1.1. I use session saver (which doesn't support
multiple windows) so i try to work in one window. Unfortunately, this means I
frequently get to the past-the-red-X stage and have to dig through my old tabs
and close some. couldn't you have a left/right scroll button?

    
    

    
  
(In reply to comment #54)
> This is still true with the latest snapshot. If you open up a lot of tabs
> (40ish) there is no way to get to those that flow past the red X close button. 

There is no way to get to them with the mouse. You can get to them with the
keyboard, however: Ctrl-Tab or Ctrl-Shift-Tab switch to the next or previous tab
(respectively), in round-robin fashion, and the "hidden" tabs are included in
the cycle. For instance, to get to the last (hidden) tab, click on the first
(visible) tab at extreme left, then hit Ctrl-Shift-Tab.

One way to fix the problem (at the expense of some screen real-estate) is by
means of the Flowing Tabs extension (see comment #51 ). (If you decide to
install it, I recommend limiting the tab width via an entry in userChrome.css).
Other extensions have also been mentioned in other comments. YMMV.
> 
> I really hope this is fixed in 1.1. I use session saver (which doesn't support
> multiple windows) so i try to work in one window. Unfortunately, this means I
> frequently get to the past-the-red-X stage and have to dig through my old tabs
> and close some. couldn't you have a left/right scroll button?

Depending on how you set its options, Session Saver does support multiple
windows. I use Session Saver myself, with two Firefox windows. I have unclicked
"Restore all windows into one" in the Session Saver options, and whenever I
close and reopen Firefox, my two windows are reopened with their respective
contents. But it means that I have to close it by the File -> Exit menu, not by
clicking the red [X] at top right.

Best regards,
Tony.

    
    

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

    
    

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

    
    

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

    
    

    
  
IMHO you can't indefinitely make the tabs smaller, neither would I fancy a
solution of multiple rows of tabs.
I would rather go for the solution reported in through this bug :
<a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=236798">https://bugzilla.mozilla.org/show_bug.cgi?id=236798</a>
This implies to have a window, menu or whatever which would allow you to access
them throught their names.

    
    

    
  
IMHO, a separate window or a dedicated tab for navigation purposes is not what
people that use tabbed browser expect to see. I would better see 2nd, 3rd, and
so on line of tabs within current browser. What do you think?

    
    

    
  
Have you ever seen the MSN Toolbar for IE, which adds tab support? It uses a
system which is quite simple. When too many tabs are opened, it creates two
small buttons of 'right' and 'left', right beside the close 'x' button. With
them, you can navigate between all opened tabs with no trouble at all.

I think creating multiple lines of tabs isn't a very nice solution, specially
for people who use smaller screen resolutions.

    
    

    
  
A drop-down indicator such as you get on the bookmarks toolbar seems the obvious
choice. I'm not sure how all this stuff about multiple lines of tabs arose,
that's just horrible... :-)

    
    

    
  
Looks like the opinions diverge on how to fix this particular problem:

- an additional window or menu with tab names
- left- and right-pointing buttons
- multiple rows of tabs

I believe that each of these solutions has its advantages and inconvenients, 
so why not let the user choose? A different extension for each possibility 
(e.g. Flowing Tabs for the 3rd one) might be the way to go.

    
    

    
  
In my opinion the way TabMix works is pretty good. You have a choice to get all
tabs in one row or up to three rows, can choose width of the tabs and and and.
Something like that implemented would be nice.
Having a separate window/menu/dropdown for navigation through the tabs seems
contradictory to the idea of having tabs in a browser since I want to use the
tabs to navigate like I do on the taskbar in windows (and yes, before I found
TabMix I had a taskbar with 3 rows of programs in it, around 80 only for
Firefox...).

    
    

    
  
Personally, I can accept option with arrow buttons for tab-line scrolling.
However, I will accept with one single reservation. Scrolling buttons must
appear only after tabs become as small as possible.

    
    

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

    
    

    
  
(In reply to comment #61) 
> Have you ever seen the MSN Toolbar for IE, which adds tab support? It uses a 
> system which is quite simple. When too many tabs are opened, it creates two 
> small buttons of 'right' and 'left', right beside the close 'x' button. With 
> them, you can navigate between all opened tabs with no trouble at all. 
 
You mean MSN copied Konqueror before Firefox did...? Go back and see comment #3 
from a year and a half ago - the only difference now is that Konqueror's tab 
bar looks like Mozilla's with the new tab button at the left hand end and the 
close button at the right hand end with the dual button just to the left of 
that. 
 
 

    
    

    
  

      
      
      
      

        Attached image
          
        Solution(s)
        — 
      

    


  
Having fun reinventing the wheel ?

    
    

    
  


  
This HTML file is an example how you can re-create the bug again and again.
Please	replace links with some other links, best are local filesystem links -
I am sure you want to do so if you don't want to pay high bills for nothing.
This one, although alpha example, worked for me very good.

    
    

    
  
Why not include the functionality of the TabMix extension into FF? As has been
pointed out, different solutions are good for different users (I prefer several
rows of tabs because this gives me instant access to all without repeated clicks
on some scroll button).
But - all approaches are better than the current mess.

Including the TabMix functionality might be an easy apprach to get started and
might allow to streamline the UI in later releases.

Remember that other browsers do in the meantime not only include tab
functionality but increasingly are able to handle tab overflows *without* the
buggy mess we have in FF at the moment. 
Assignee: bugs → nobody
Hardware: PC → All
Version: unspecified → Trunk

    
    

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

    
    

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

    
    

    
  
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, so would happily
convert one of the solutions into a patch.

Apologies for the long post!

    
    

    
  
(In reply to comment #74)

> Apologies for the long post!

No apologies necessary!

I agree! Without seeing your implementations, option #3 (the scroll bar) sounds
superior to me.

    
    

    
  
(In reply to comment #74)

Which extension - do you make it available somewhere for others to test?

    
    

    
  
I think if it would be possible, I'd vote against this bug since any further
posting is useless from my point of view - the bug should be closed by now. 

100% solution to this issue is installation of very popular TabMix Plus
extension (currently 0.2.5.1, I think), fully configurable, with multirow set to
maxrows, available on mozdev.org. Has only one bug - installation resets tab
browsing options to defaults which may even convenient in some situations. 
Other option is Tab Mix - original source for TM Plus - works on same
principles. Has automatic multirow, but tricky and won't work smooth in all Foxes.

They both work up to FF1.6a1, latest builds (I use also Nightly Tester Tools
extension for compatibility issues, so this might not be true without it), so I
please anyone to browse extensions before firing up a bug report.

    
    

    
  
Extensions add features, they don't fix bugs.
Just my 2 cents ...

    
    

    
  
(In reply to comment #78)
> Extensions add features, they don't fix bugs.
> Just my 2 cents ...

Exactly - and extnesions are optional and - as TabMix - often come with
additional features or consequences a user might not and indeed does not have to
accept. 

It is rather easy: handling of too many tabs is broken in a rather embarrassing
way and needs to be fixed. Several ways of fixing this are possible and the
first step to do is to come to a final conclusion on what UI to choose to fix this. 

There is no way to make everyone happy by any fix: if we pick one of the many
options, people who prefer others will complain, if we implement several with a
preference to choose, those who want FF to romain slim and with a simple UI will
complain.

Therefore I propose to implement something that is simple AND consistent with
the rest of the FF interface to fix the bug and leave it to extensions to make
all the people happy who want more flexibility or something else.

What I think is most consistent with the current FF interface is to use the same
approach as is used when the bookmark bar flows over: show a ">>" symbol that
will show everything not in the bar in a menu (BTW that should be done for *any*
bar, including the menu bar).

Such a solution would be consistent, probably rather easy to implement and also
consistent with a couple of other applications that use the same scheme (e.g.
Eclipse). 

Once it is decided to proceed that way, we can look if there is already an
extension out there that has code to implement this and whether the extension
author would be willing to help or donate the code to be used as a starting point. 

    
    

    
  
I suggest having a chevron at each end of the tab bar, which when selected shows
only tabs forced off that end of the tab bar. When switching to another tab, the
visible area of the tab bar should be scrolled to centre the newly-activated tab
in the visible area of the tab bar.

    
    

    
  
I would agree with the chevron solution, it's the most UI consistent.  Other
addons should feel free to change it with optional solutions.  As far as
placement of the newly clicked tab from the drop down though: it should merely
be placed last in line visible while the _previous_ last in line bumps into the
drop down list.

    
    

    
  
(In reply to comment #76)
> Which extension - do you make it available somewhere for others to test?
I will soon, once I've removed a few bugs...

(In reply to comment #78)
> Extensions add features, they don't fix bugs.
Exactly, a solution should be implemented so that the default behaviour works,
then users can install extensions to change the behaviour if they wish to (and
know how to).

(In reply to comment #80)
> I suggest having a chevron at each end of the tab bar, which when selected shows
> only tabs forced off that end of the tab bar. When switching to another tab, the
> visible area of the tab bar should be scrolled to centre the newly-activated tab
> in the visible area of the tab bar.
Hmm why didn't I think of that? Ok, so there is a sane way of implementing
chevrons. It would definitely be the most consistent UI, though I don't think it
would be particularly easy to use, mainly because to be consistent the resulting
popups should use arrowscrollboxes to show tabs which can't fit in the popup,
however these are a bit of a useability nightmare as I mentioned earlier.
[offtopic]Why don't popups just use overflow-y:auto instead of
arrowscrollbox?[/offtopic]

    
  
Flags: blocking-aviary2?

    
    

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

    
    

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

    
    

    
  
Tab overflow needs a fix, I've been leaning towards the chevron's solution for a while now, especially since its faster than the scrollarrow and in theory works better with DnD
Assignee: nobody → mconnor
Flags: blocking-aviary2? → blocking-aviary2+

    
    

    
  
Mike, can you update the wiki with documentation about how you plan to make this work. 


Alias: tab-overflow

    
    

    
  
I have covered this in some detail mentally before and here are my notes:

Given that the tabbed browser has these features:
- drag and drop reordering
- keyboard accessible navigation

... and that we want to try retain those even for overflowed tabs (dragging a tab back to the start of the set when it's at the end is occasionally useful):

Chevron Menu Only (Safari)
- When you select an item from the overflow menu, the indication of selected tab vanishes from the strip, which looks weird and gives no indication as to what is actually selected.
- D&D and keynav break, unless you want to implement various horrid hacks to show the popup menu and allow dragging/navigating into it, which almost certainly don't work on Mac.

Chevron Menu with Scrolling Strip
- When you select a tab from the menu, the strip is zoom-scrolled so that the tab is visible. This solves the "no visible selected tab in tab strip" issue that affects the plain Chevron Menu solution. However when the strip is scrolled the set of non-visible tabs changes. There may be more non-visible tabs to the right and now left of the strip, meaning two menus need be shown, perhaps at alternate ends of the tab strip. This sounds cumbersome. 
- D&D and keynav probably work in this case though. 

Chevron Menu with Tab Reordering (Visual Studio 2005)
- LIFO ordering on the strip, sense of insertion is inverted. New tabs appear at the start of the strip and older ones move to the right until they are eventually evicted into a menu. Selecting an item from the menu re-inserts the item at the start of the strip. I have been using VS2005 for over a month now and this is a disaster. The delicate order of tabs that some users have is not only not preserved, it is actively destroyed. They should have left it the way it was. 
- Doesn't easily support D&D or keynav to non-visible items. 

Scrolling Strip (buttons) (Visual Studio 2003 and earlier)
- Supports D&D and keynav while maintaining a single static piece of UI (scroll buttons)
- Setting the scroll speed correctly is likely to be a challenge. 
- No instant way of getting to a hidden tab - speed of access relies on scrolling and dexterity. 



    
    

    
  
I also favour the "Chevron Menu with Scrolling Strip" solution, which is pretty much what people were talking about from comment 80 onwards. Maybe fears about the unwieldliness of chevrons at both ends of the tab bar are warranted, but using them seems intuitive enough in my imagination ;)

Wouldn't that approach still break D&D on Mac, though? (as per Ben's comment 87 under "Chevron Menu Only"). If it can't be implemented that way, I'm rather fond of the "Scrolling Strip (buttons)" solution. Dragging a tab towards a location off the visible bar should be intuitive enough, much like dragging a file to a scolled-off location in a window. But, as mentioned, getting the scrolling speed right can be a nightmare, since various OSs still don't seem to handle it very well ;P

    
    

    
  
What happens with the chevron solution if there are more tabs open than can fit on a menu that drops down from the chevron?

    
    

    
  
In that case, we'd end up with scrollbuttons (i.e. like the bookmarks chevron).  It'd be a pretty extreme case (i.e. on something beyond 30 tabs even on a 1024x768 screen), but there's just no way to avoiding scrolling entirely at some value of N tabs.  There's another option that might work better than needs some more thinking before I file it.

    
    

    
  
So, just so I'm clear, with the chevron solution > 30 tabs will show a chevron at the end of the tab toolbar and another chevron at the end of the menu that drops down? Doesn't that mean 60+ tabs will cause the user to encounter 6 different chevrons during navigation (two on each scrolling menu and one at each end of the tab toolbar)?

    
    

    
  
(In reply to comment #91)
> So, just so I'm clear, with the chevron solution > 30 tabs will show a chevron
> at the end of the tab toolbar and another chevron at the end of the menu that
> drops down? Doesn't that mean 60+ tabs will cause the user to encounter 6
> different chevrons during navigation (two on each scrolling menu and one at
> each end of the tab toolbar)?
> 

No, the menu will have a scrolling arrow (or vertical chevron, if you will) at each end. Using these arrows won't make another menu to fold out from the first one, it will make the menu scroll vertically until your mouse leaves the arrow. Try it with the context menu on image links (especially with many extensions adding to it) for an image-link about halfway between top and bottom of the screen, you'll see what I mean.

    
    

    
  
Correct me if I'm wrong, but there will be two menus right (one at each end of the tab toolbar)? That means that navigating from a tab located on one menu to a tab on another -- if you have 60 or more -- will require traversing 6 different chevrons along the way.

If there aren't going to be chevrons at both ends, where do does the first tab currently displayed in the window go when you scroll down the list? It sure would be a strange UI to scroll the list but leave the tabs displayed on the tab toolbar fixed in position. 

    
    

    
  
(In reply to comment #93)
> Correct me if I'm wrong, but there will be two menus right (one at each end of
> the tab toolbar)? That means that navigating from a tab located on one menu to
> a tab on another -- if you have 60 or more -- will require traversing 6
> different chevrons along the way.
> [...]

Ah, I see. That would be a really extreme case. Depending on your "minimum tab width" and "menu font size" settings, it may require 100 tabs or more (overflowing the left menu, overflowing the tab bar, overflowing the right menu, add the three results); in that case you may be better off with either the "Flowing Tabs" extension (which is also an optional part of the functionality of "Tab Mix Plus") which flows the tabs to several "tab bars" one under the other, or the "Tab Menu" extension, which adds a menu of all tabs on your main menu bar, just left of the "Help" menu. It's all a question of how many tabs you want to open at the same time and which of the currently available solutions you want to use to handle them.

    
    

    
  
(In reply to comment #93)
> Correct me if I'm wrong, but there will be two menus right (one at each end of
> the tab toolbar)? That means that navigating from a tab located on one menu to
> a tab on another -- if you have 60 or more -- will require traversing 6
> different chevrons along the way.

As I understand it (maybe I'm wrong)... Say you have tabs A-Z, with only tabs A-G visible, and the rest in an overflow menu to the right (I'm assuming only 7 tabs can fit in the window, for the sake of simplicity). If you select tab Q from that menu, then tabs K-Q would now be visible, with tabs A-J in a menu off the to left and tabs R-Z off to the right.

Is that correct? If so, then to access another new tab that was in an overflow menu, then you'd usually only have to use 1 chevron (to access the menu) and at most 2 (to access the menu and then scroll down it if the menu was longer than the screen). You'd never have to travel through 2 menus in the one action, as the last focused tab would always be in the visible tab bar.

    
    

    
  
yeah, that would be about right.  The 30 tabs is a minimum number assuming you're on the first tab, and you're on a smallish screen.  On a 1920x1200 display, it'd be more like 45 or higher.  Even anecdotally, the number of people who use more than 30-45 tabs makes it an edge-to-corner case.

    
    

    
  
First and foremost, I have implemented just about every possibility that has been discussed to date (and the ability to switch from one to another while running), and released them all as an extension, which I highly recommend to UI testers (it should be stable enough for general use too): http://jomel.me.uk/software/firefox/toomanytabs/

(In reply to comment #90)
> In that case, we'd end up with scrollbuttons (i.e. like the bookmarks chevron).

Please no! Having chevron popups scrolled by an arrowscrollbox would be worse than having the tab bar itself just be an arrowscrollbox (itself an unattractive proposal), since it would boil down to the same thing except with a clumsy intermediate step.
Surely it'd be much more effective to just put a scrollbar on the popup. Arrowscrollboxes are a nice idea, but lets face it they're designed for normal menus with a few items overflowing, not for hundreds of items all of which need to be easily accesible (imho the bookmarks chevron should be the same, but that's a different bug).
Another option is to have a multi-column popup (as is the default in my extension), which would allow immediate access to hundreds of overflowing tabs before having to consider a scrolling mechanism.

Incidentally, if one chevron were prefered, this could be done by including all tabs in its menu, including those onscreen (yes, technically it wouldn't be a chevron, but that's not the point). Having such a menu could in fact be useful in addition to whatever is implemented here (e.g. accessible via the Go menu).

Also, have you considered making the tab bar act like the pretty effective Windows task bar? It effectively lets users choose between having a multi-row or single row solution by defaulting to one but letting users drag the top edge. If there are more tabs than rows available, buttons are shown to scroll up and down through the rows (a scrollbar could work too). 3 rows might be a good default maximum though as it guarantees a good number of tabs before and after the current one being shown.

P.S. it would make a lot of sense to fix the trivial but signifiant bug 161836 at the same time as this, as A) it means people only have to adapt their understanding of tabs once, and B) when many tabs are open, as this will enable, it is particularly vital for new tabs to be opened near to the current one, rather than at the other end of the tab bar which could be a minute's worth of scrolling away (especially if an arrowscrollbox -like or -based solution is used, which I discourage due to its poor useability).

    
    

    
  
(In reply to comment #97)
> First and foremost, I have implemented just about every possibility that has
> been discussed to date (and the ability to switch from one to another while
> running), and released them all as an extension, which I highly recommend to UI
> testers (it should be stable enough for general use too):
> http://jomel.me.uk/software/firefox/toomanytabs/

Different people, different solutions. I use Tab Mix Plus and it has what I like. YMMV.

[...]
> Incidentally, if one chevron were prefered, this could be done by including all
> tabs in its menu, including those onscreen (yes, technically it wouldn't be a
> chevron, but that's not the point). Having such a menu could in fact be useful
> in addition to whatever is implemented here (e.g. accessible via the Go menu).

That's what the Tab Menu extension gives (a menu of all tabs, in this case in the main menu bar).

[...]
> P.S. it would make a lot of sense to fix the trivial but signifiant bug 161836
> at the same time as this, as A) it means people only have to adapt their
> understanding of tabs once, and B) when many tabs are open, as this will
> enable, it is particularly vital for new tabs to be opened near to the current
> one, rather than at the other end of the tab bar which could be a minute's
> worth of scrolling away (especially if an arrowscrollbox -like or -based
> solution is used, which I discourage due to its poor useability).
> 

The reporter of that bug wants to always have new tabs open to the right of the current tab. Please don't! I much prefer new tabs to open at the end of the -- possibly multi-line -- tab bar. (Tab Mix Plus offers a choice between both behaviours, which is OK by me. I just don't want to be forced to change to something IMHO worse than what I already have.)

    
    

    
  
I go back and forth on multicolumn menupopups, they're great if we're actually trying to support hundreds of tabs at once, but that is an extreme edge case that I don't intend to gate our design thinking against.  There will always be room for extensions to better manage corner cases.

By chevron, I did of course mean arrowscrollbutton, since my current assessment is that its a relatively rare action to go from N to > N+20.  There's also the processing in two dimensions instead of just one factor, which will slow down visual scan time/processing in the common (smaller jumps) case.

I don't think open to right is especially interesting, intuitive, or effective for most users, or even completely in the scope of this bug.  Its actually somewhat useful in the more extreme case, but not so much in the normal 4-8 tabs case that tends to be the normal user limit (anecdotally).

    
    

    
  
> Its actually somewhat useful in the more extreme case, but not so much in the
> normal 4-8 tabs case that tends to be the normal user limit (anecdotally).

I use a bookmarks folder containing all the blogs that I want to check out regularly, and I always open them all at once. That means I regularly have a tab bar containing a "to-read list" of more than 30 documents. You don't get to the 30-tab limit by normal usage, but this use of bookmark folders easily reaches this limit.

    
    

    
  
It is really very unhandy that a new tab, opened from a link in the first tab, opens far to the right. Even with multiple rows.
First I could not discover where the tab was located so I couldn't read and close it. 
With multiple rows you can see at least where it is, but it is still illogical. 

    
    

    
  
(In reply to comment #99)
> I go back and forth on multicolumn menupopups, they're great if we're actually
> trying to support hundreds of tabs at once, but that is an extreme edge case
>
My reasoning was that multicolumn popups do no harm if only one column is needed, yet make things much easier in the 'edge cases'.

> There's also the processing in two dimensions instead of just one
>
Perhaps if only one and a half columns are needed it is a tiny bit harder, but as soon as 2 or more are needed the time-gain of not having to use a slow arrowscrollbox mechanism easily overrides any temporary confusion.
(faster arrowscrollboxes wouldn't help as you couldn't see where you are; a scrollbar would solve this, but it would be unusual UI).
 
> my current assessment is that its a relatively rare action to go from N to
> N+20.
>
It happens whenever users open a tab if new tabs insist on opening at the far right. And users will from time to time flit from one group of tabs to another.

> I don't think open to right is especially interesting, intuitive, or effective
> for most users, or even completely in the scope of this bug.  Its actually
> somewhat useful in the more extreme case, but not so much in the normal 4-8
> tabs case that tends to be the normal user limit (anecdotally).
Suppose a user has 3 tabs on three different topics, and opens a related tab from the 1st tab. It will appear far from the first one (and worse, out of sight if > ~30 tabs), causing the user's tabs to become fragmented. That can never be good...

    
    

    
  
(In reply to comment #102)
[...]
> Suppose a user has 3 tabs on three different topics, and opens a related tab
> from the 1st tab. It will appear far from the first one (and worse, out of
> sight if > ~30 tabs), causing the user's tabs to become fragmented. That can
> never be good...

He can always reorder the tabs by drag-and-drop (with MiniT+ in Firefox 1.0.x, without any extension in 1.5). I could imagine other cases where opening immediately right of the current tab "could never be good". Why not let the user choose by means of a preference (as is already the case in the Tab Mix Plus extension)?

    
    

    
  
I don't know where to put the information, but in the latest build the close buttons on the tabs don't work anymore if you have fixed width tabs by means of .css. So now there are only two options left:

1. no fixed width tabs anymore;
2. an extension that puts close buttons on tabs. 

    
    

    
  
Just downloaded 'Too Many Tabs' extension to check out the various possible options... The one that seemed best is:

-> Just the Tab Picker (List of all open tabs highlighting the current selected..close button should be added to this list)
-> Overflow Menus + Tab Picker

I could even make do only with the Tab Picker (Menu) to the right end of my tab bar since it basically shows my current active tab as well as the ones to the left and right of it. Dividing the Overflow menu as two chevrons, one at each end IMHO will not be the best from a usability point of view, since a user will have to move his mouse to the extreme left or extreme right of his screen to select tabs. 

Just a Tab Picker (Menu) will solve this problem in one go showing all the tabs the user has open, highlighting the tab which is selected and showing the remaining ones above or below the highlighted tab in sequence.

In addition, the Tab Picker (Menu) should also have the following functionalities:
- Display of Close tab buttons, so that the user can directly close the tab from the list instead of having to open it first
- Menu List should be 'Fixed' i.e. should remain open. The list should not close if the user 'closes' a tab from the list or just selects a tab (mouse-down) for DnD. The list should close ONLY WHEN the user selects (clicks and releases the mouse) a tab from the list.

Thanks.
Severity: minor → normal
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Firefox 2 alpha1
Target Milestone: Firefox 2 alpha1 → Firefox 2 alpha2

    
    

    
  
*** Bug 330950 has been marked as a duplicate of this bug. ***
Whiteboard: SWAG: 6d
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1

    
    

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

    
    

    
  
load-balancing tabbrowser stuff to sspitzer
Assignee: mconnor → sspitzer
Status: ASSIGNED → NEW

    
    

    
  
gah.  s/.org/.com/!
Assignee: sspitzer → sspitzer

    
    

    
  
As the problem is still existing from firebird 0.x to firefox 2.0a3, it looks like there are no efforts to fix this.
Thereby this is very annoying for users who work with many tabs. All tabs beyond this holy border are not reachable.
Making multiple columns is better and even squeezing tabs to 5mm width is it too. At least make them accessible by a dropdown menu or something.
Maybe let the user choose, which one of these he would prefer.


    
    

    
  
(In reply to comment #110)
> As the problem is still existing from firebird 0.x to firefox 2.0a3, it looks
> like there are no efforts to fix this.
> Thereby this is very annoying for users who work with many tabs. All tabs
> beyond this holy border are not reachable.
> Making multiple columns is better and even squeezing tabs to 5mm width is it
> too. At least make them accessible by a dropdown menu or something.
> Maybe let the user choose, which one of these he would prefer.
> 

If you would have read the top part of this bug you would have seen that the whiteboard says "SWAG: 6d" meaning 6days until this should be fixed, priorty is 1 meaning very high priority (actually the highest priority), target is Firefox 2 beta 1, and this bug is also blocking 2.0 release. Hold your horses and please don't comment in bugs unless you are posting something to help out. General me too comments or trying to rush developers into fixing things only make the process slower since the devs have to read another comment in the bug report.


    
    

    
  
Sorry, too rude last time.
It's only that I follow this bug since some 0.x version of firefox and tonight I saw it while testing the 2.0a3 and got kind of impatient.

I am very happy to hear about SWAG:6d (what I didn't know what it meant before).

But my post was not all about whining. I made suggestions how to give the user the choice how to handle his tabs. But I think the devs already considered that. :)

Sorry again for this last non-helpful post.
regards

    
    

    
  
I agree with many of the commenters in this bug that something needs to be done for ff 2.0, and I agree with many of the commenters in this bug that whatever we do will not please everyone.

after reading this bug and playing around with john mellor's "too many tabs" extension (see http://jomel.me.uk/software/firefox/toomanytabs/, nice work!) I think the ff 2.0 solution for this should be a single row of tabs, with the right and left arrows (together, at the far right of the toolbar.)  in the too many tabs extension the right / left arrows are on either side of the tab bar, and I think it would be better if they were closer together (like mac scrollbar buttons).

as several people pointed out, this is the solution that several other applications have chosen for this problem (konq / visual studio 2003 / the MSN Toolbar for IE approach)

additionally, I we should come up with a reasonable min width for tabs, so they will start out as wide as they do now, but then as more tabs are opened they will shrink to a point, and then we'll show the scroll button UI.
Status: NEW → ASSIGNED

    
    

    
  
ben has tried out the "too many tabs" extension.

the plan is for me to take a look at how john's extension works, make just the changes for the konq / visual studio 2003 / the MSN
Toolbar for IE approach (but move both buttons to the far right) and then see if I can make it scroll more smoothly.

    
    

    
  
(In reply to comment #113)
> I think the ff 2.0 solution for this should be a single row of tabs, with the
> right and left arrows

Hmm, if this solution is chosen then I'd strongly suggest we (in the long run, even if there isn't time before Fx2) supplement it with a menu somewhere for quick-access to tabs.
Otherwise common cases like switching from a tab at the beginning to a newly opened tab (at the far right) remain very lengthy.
The location of such a menu isn't important: it could be a toolbarbutton as in IE7 (and too many tabs), or even part of/instead of/as well as the Go menu.

> as several people pointed out, this is the solution that several other
> applications have chosen for this problem (konq / visual studio 2003 / the MSN
> Toolbar for IE approach)

Although with hindsight Microsoft have supplemented this in IE7: as well as scroll arrows to either side, there is a dropdown menu listing all tabs with the visible ones highlighted, and a tab thumbnail picker (much like the Firefox Showcase or foXpose extensions).

> with the
> right and left arrows (together, at the far right of the toolbar.)  in the too
> many tabs extension the right / left arrows are on either side of the tab bar,
> and I think it would be better if they were closer together (like mac scrollbar
> buttons).

That would though increase the distance you have to move your mouse to scroll left then select the leftmost tab.

(In reply to comment #114)
> the plan is for me to take a look at how john's extension works, make just the
> changes for the konq / visual studio 2003 / the MSN
> Toolbar for IE approach (but move both buttons to the far right)

The way I implemented that approach was basically to put the tabs into an xul:arrowscrollbox instead if the existing xul:hbox. If you want to implement it that way it'd probably be easier to just tweak mconnor's code in bug 318168 attachment 223204 [details] [diff] [review], which is pretty complete (notably it already includes things like the css to make the arrows horizontal, and the code to shift the tabs when appropriate onselect and on tabclose).

If you want the arrows on the right you'll have to either extend the arrowscrollbox binding, hack arrowscrollbox itself, or move the left autorepeatbutton at runtime using DOM JS.

Alternatively you could just insert two buttons and create your own scrolling mechanism by wrapping the tabs in a scrollbox (or even just collapsing tabs on the left side of the tab bar), though it's probably not worth it, unless users find the quirky onhover behaviour too annoying.

> additionally, I we should come up with a reasonable min width for tabs

Perhaps around 60px? (mconnor used 140px in his patch, but that seems excessive).

> and then see if I can make it scroll more smoothly.

The default for an arrowscrollbox is to scroll by a tab at a time. mconnor's solution in his patch was to globally change arrowscrollbox to scroll by 20px at a time, but if you wanted to fine-tune it, or perhaps even add an accelerating scroll amount, you'd have to change the oncommand attributes of the autorepeatbuttons in the arrowscrollbox (assuming you use one), either by extending the arrowscrollbox binding or at runtime using DOM JS.

(changing the repeat interval would be more complicated, http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsScrollBoxFrame.cpp#109 seems to use the defaults of 250ms initial followed by 50ms each time in http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsRepeatService.cpp#48) 

    
    

    
  
whoops!

I didn't realize (even though I had looked at it) that mconnor's patch in bug 318168 is already an implementation for the scrolling tabstrip.

I'll start with his patch (which needs porting to pinstripe, see his bug 318168 comment 2) and report back today.
Depends on: tabbedbrowsing

    
    

    
  
> I'll start with his patch (which needs porting to pinstripe, see his bug 318168
> comment 2) and report back today.

oops, I never reported back.  the patch in bug #318168 has been ported to pinstripe and will fix this bug.

reducing swag to 1 day, giving time to spin off any issue from this monster bug to new bugs once the fix for bug #318168 lands.
Whiteboard: SWAG: 6d → SWAG: 1d

    
    

    
  
the fix for #318168 has landed, so this is fixed (on the trunk at least.)
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED

    
    

    
  
.tabbrowser-tabs > hbox {
  display: block !important;
}
.tabbrowser-tabs tab {
  min-width: 100px !important;
}

(= fixed width) does not work anymore now.

    
    

    
  
(In reply to comment #119)
>
Extension Tab Control with this function still working.



    
    

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

    
  
Whiteboard: SWAG: 1d → SWAG: 1d 181b1+

    
  
Depends on: 343251

    
    

    
  
My apologies if this is not the right place to post this, which it probably isn't, but how about making it possible to right-click on the arrow buttons to get a (selectable) drop-down menu?

It would look somewhat like this:

http://img207.imageshack.us/my.php?image=firefoxdropdown3ll.jpg

PRO(S): No extra UI clutter, and it should satisfy a lot of those who are unhappy with the arrow-buttons solution.

CON(S): It wouldn't be obvious that it was possible to get a drop-down menu.

    
  
Depends on: 344171

    
    

    
  
Verified fixed with Windows, Mac and Linux with 2.0.b1rc3 builds
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1

    
    

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

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: