RFE: Provide a way to tile tabs into more than one row (tab overflow)

VERIFIED WONTFIX

Status

enhancement
VERIFIED WONTFIX
17 years ago
6 years ago

People

(Reporter: ddkilzer, Assigned: jag+mozilla)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments)

Reporter

Description

17 years ago
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).
Reporter

Updated

17 years ago
Blocks: 126299

Comment 1

17 years ago
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 ***
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE

Comment 3

17 years ago
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.
Reporter

Comment 4

17 years ago
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.  :^)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter

Comment 5

17 years ago
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?
Summary: RFE: Provide a way to tile tabs into more than one row → RFE: Provide a way to tile tabs into more than one row (tab overflow)
Reporter

Comment 7

17 years ago
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...

Comment 10

17 years ago
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.

Comment 12

17 years ago
<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

Comment 14

17 years ago
(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. 

Comment 15

17 years ago
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.

Comment 17

17 years ago
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.

Comment 18

17 years ago
Bug 106927 is about scroolling tab-row. 
I think this should be marked a dup of bug 106927.
Reporter

Comment 20

17 years ago
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 ***
No longer blocks: 126299
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → DUPLICATE
VERIFIED DUP
Status: RESOLVED → VERIFIED

Comment 22

17 years ago
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.

Comment 24

17 years ago
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.

Comment 26

17 years ago
Reopen to WONTFIX.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 27

17 years ago
WONFIX.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WONTFIX
VERIFIED WONTFIX
Status: RESOLVED → VERIFIED
*** Bug 150413 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
(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
  }
You need to log in before you can comment on or make changes to this bug.