A friend asked me today if Mozilla could tile its tabs similar to the way that Opera does. After doing some querying in Bugzilla, I couldn't find an RFE requesting the same functionality, so I filed this bug. This is especially helpful when you open many tabs on a single web site that has the same (or no) favicon.ico, since the last thing you'll see is the icon once most of each page's title gets truncated. (I've run into this on bugzilla.mozilla.org while searching for a tiling tab bug. :^) This would come in handy after reordering of tabs via drag-and-drop were available (Bug 105885).

This would also help with the problem of overflowing the tab bar when too many tabs are open.

Duplicate of "Tile/cascade tabs" (and see also bug 122701) *** This bug has been marked as a duplicate of 108589 ***

This is not a dup of the misleadingly-titled bug #108589. That bug is for the ability to view multiple tabs' content at once (making tabs act like nested windows in some Windows apps). This is just for tabs spilling over to another line when there is no more room on the first. It differs from #122701 in that it does not provide multiple lines as individual groups, just as a way of handling tab-bar overflow.

Reopening per Garth Wallace's comments. (Thanks!) In Bug 122701, Hixie quotes the following web page for not allowing mutiple rows of tabs: http://www.iarchitect.com/tabs.htm The main difference between this web page and implementing multiple tab rows in Mozilla (for overflow purposes) is that the _user_ is controlling the behavior in Mozilla. In a dialog from a piece of software, the user has no direct control over how many tabs there are or how they are positioned. If implemented properly in Mozilla, the user would have sufficient control (in my opinion) over the behavior to avoid the issues documented on that web page. Besides, all the tabs represent web pages. To play devil's advocate, one could argue that because users are able to easily create an overflow condition with the current implementation of tabs, this is a bad user interface design and the feature should therefore be taken out. I don't think that would fly well with current tabbed browser fanatics. :^)

Proposed user interface (glued together from two browser windows).

Well we certainly need _some_ mechanism for handling tab overflow... I don't know if that is the best way, but it is certainly one way. As a user who _frequently_ opens over 50 tabs at once (one per bug that has changed since I last looked at my cc buglist), I don't think I would like the multi-row overflow solution. Should this bug cover the more general issue of what to do when we have too many tabs for one row, leaving the exact UI solution up to the experts?

That's fine if we change the focus of this bug to emcompass a general solution for tab overflow. I guess I'm at a loss for ideas other than the ones I've already read about. And I don't consider this a valid solution: :^) <script type="application/x-javascript"> <!-- alert('Buy a bigger monitor or use a higher\n' + 'resolution on your monitor!'); // --></script>

[In Tabbed Browsing prefs panel]: When there are more tabs open than will fit on one row: (*) Create additional rows of tabs ( ) Scroll through tabs using arrows at either end of tab bar ( ) Hide certain tabs: ( ) leftmost ( ) middle ( ) rightmost ( ) oldest ( ) medium-aged ( ) newest [X] Provide dropdown list of hidden tabs, and allow one to be selected. I would choose to hide the middle tabs myself, viewing them as a queue of pages to work my way through from the left, sometimes skipping one and going back to it, and occasionally detouring to check out something new in a tab or two on the right. Note also that the ability to move tabs to another window (a separate bug) is also relevant, but is really not what I want, personally, since I really only want one window.

You have got to be kidding! We'll just pick one and do it that way, no need to have a gazillon prefs for this kind of thing...

This should be enough: When there are more tabs open than will fit on one row: (*) Create additional rows of tabs ( ) Scroll through tabs using arrows at either end of tab bar (OT: actually isn't possible to access specific tab from menu?)

Guys we really don't need a pref at all, we just need to pick one and implement it. We have too many prefs already.

<off-topic> IMHO fight between users ('we need preferences for anything') and developers ('we are able to choose right solution and most of preferences are useless') about preferences will ends with two modes of Preferences panel. Basic for common users (aka BFU) and Advanced for geeks and power-users. Advanced will be a complete set of all preferences, Basic will be part of it, rest will be setted on default values. </off-topic>

No, these fights will result in the people wanting 900 checkboxes being told to go away, and continuing efforts continued to simplify our bloated pref dialog :-P

(OT: Ben: Resolution of these fights is only one: simple Preferences layout as exists now and advanced Preferences layout as in bug 17199 (pretty old). But marking every any new preference undesirable is IMHO bad way - you all are making really big (and good =)) product for many people, so a needs of people could be different.) On topic: Both proposed solution are useful: Tabs in several rows are fine if you need access between different tabs (browser-based monitoring application for example). One row with scrolling is IMHO enough in all other cases (and should be default/first implemented). BTW Sometimes I have opened about 30 tabs in one window (opening auctions on eBay). When browser couldn't fit next tab in row of browser width, [x] tab button disappear and tabs are created outside visible part of browser. Futhermore, content window is loosing in this moment vertical scrollbar and some page content isn't visible. I will attach screenshot. With mentioned condition is this bug report solution for bug, not enhancement.

On screenshot you could see long page of last tab. Vertical bar isn't visible (but page continues below), (x) tab-button isn't visible too, etc.

Yes, this is why I prefer the scrolling idea than the multi-row idea -- when I need this, I have over 100 tabs open, and multiple rows would just swamp my screen with tabs until I ran out of vertical space as well as horizontal space.

The problem I see with a scrolling tab-bar is that it breaks the visual metaphor of a stack of manila folders. Not sure if that's a big consideration though.

Bug 106927 is about scroolling tab-row.

I think this should be marked a dup of bug 106927.

Yay! Another duplicate of Bug 106927! Clearing dependency on Bug 126299 (will add to Bug 106927). *** This bug has been marked as a duplicate of 106927 ***

VERIFIED DUP

IMHO this is not dupe - this is RFE for tabs in more than one row, bug 106927 has same problem, but different solution. This bug shouldn't be duped, maybe should be WONTFIXed or Futured.

Bugs describe problems, not solutions.

Ian: I know, what you mean and I could fully agree with you in a bit different case, but this is request for enhancement (read description and summary) and not bug report about unaccessible tabs, futhermore this RFE will not be solved by fixing bug 106927.

In that case this bug should IMHO be marked WONTFIX. We only need one method of showing tab overflow.

Reopen to WONTFIX.

WONFIX.

VERIFIED WONTFIX

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

(In reply to Hixie (not reading bugmail) from comment #25) > In that case this bug should IMHO be marked WONTFIX. We only need one method > of > showing tab overflow. Personally I prefer overflowing tabs to a second (third, etc.) row rather than scrolling them this way and that: isn't the Mozilla Mission about giving users the choice? Happily there is userChrome.css (which does not exist by default but can be created in the chrome/ subfolder of your profile) and this is what I use (I also have other stuff not related to this question): /*************************************************************** * TABS * ***************************************************************/ /* * Implement flowing tabs * Since these elements have no ID or class until 2010-12-27, we have to use the * element names (pulled from the XUL code for the tabs chrome). * * also relevant are some or all of the following about:config prefs: * browser.tabs.tabMaxWidth user set integer 300 * browser.tabs.tabMinWidth user set integer 16 * mail.tabs.tabMinWidth user set integer 150 * * KNOWN BUG: tab drag-dropping only works if the drop is on the top row. */ tabbrowser:not(#tabmail) .tabbrowser-tabs > stack > vbox > hbox > hbox /* until 2010-12-28 or before 2.1* */ { height: auto !important ; width: auto !important ; display: block !important ; min-height: 18px !important ; max-height: 80px !important ; overflow: visible !important } /* the following are for SeaMonkey 2.1b2pre dated 2010-12-29, and later builds */ /* (1) suggested by http://userstyles.org/styles/10989 "Tabs in multiple rows" */ tabbrowser:not(#tabmail) .tabbrowser-arrowscrollbox { display: block !important ; height: auto !important ; width: auto !important ; overflow: visible !important } /* (2) the following is necessary: apparently SeaMonkey has "overflow:hidden" */ /* at some inner level where Firefox has nothing, or maybe "inherit". */ tabbrowser:not(#tabmail) .tabbrowser-arrowscrollbox .arrowscrollbox-scrollbox { display: block !important ; height: auto !important ; width: auto !important ; overflow: visible !important ; -moz-binding: none !important } /* (3) if we see all tabs, no scrollbuttons are necessary. This also frees */ /* quite some real estate above and below the row(s) of tabs. */ tabbrowser:not(#tabmail) .tabbrowser-arrowscrollbox .scrollbutton-up, tabbrowser:not(#tabmail) .tabbrowser-arrowscrollbox .scrollbutton-down { display: none !important }

P.S. FWIW, My full userChrome.css is at http://users.skynet.be/antoine.mechelynck/other/userChrome-seamonkey.css