106927 - Very many TABs causes close button/throbber to scroll off screen, vertical scrollbar disappears

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Peter Lairo]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5+) Gecko/20011025

Very many TABs causes thobber to scroll off screen.

Creating many many TABs (CTRL+T) will eventually cause the throbber and print
icon to move off screen.

Better would be to pop up a dialogue saying: "Maximum numer of TABs reached.
Please close some TABs before creating new ones."

Comment 1

[Gilles Durys]

Confirming on linux 2001102521 trunk.
It only happens when I have 32+ tabs.

I don't think a message box like that would a good solution though.
We need a proper way for limiting the number of tabs *shown* in a window.

Opera and Galeon have different behaviours : Opera adds a small menu with tabs
that cannot be shown, Galeon lets you scroll the tabs bar.

Comment 2

[R.K.Aa.]

It depends on the width of your window - each tab has a minimum width it will
shrink to. When that is reached, they start pushing on the GUI.
This bug is in effect a "leftover" from bug 101774

Comment 3

[Andrew Simmonds]

Attachment: patch to fix

Comment 4

[jag (Peter Annema)]

I don't like the alert. And this also doesn't take care of the case where the
user resizes the window and "hides" tabs that way. I'd like to see a more
generic solution.

hyatt, didn't you have some plans for this?

Comment 5

[David Hyatt]

Yeah, this is not what we should do.  Tabs need to be capable of overflowing, 
and we should support horizontal scrolling of the tabs using a pair of overflow 
arrows.

Comment 6

[m.mozilla-bugs]

FWIW, I think the other proposal for handling overflow (adding a menu, like
Opera does) would be preferable to scrolling the tabs. Something like the "Tabs"
control on the Sidebar seems perfect to me.

If you go with horizontal scrolling anyway, would the scroll arrow scroll the
tabs one at a time (seems really painful), or a screenful at a time?

Comment 7

[mozilla]

How about creating multiple lines of tabs instead when there are more than will
fit in one line?  Note that the scroll bars, and the close tab X, also disappear
(at least under Windows 98), not just the throbber.  To my mind, the scroll bars
are most important.  Personally, I think this is a bug that should be fixed for 1.0.

Comment 8

[Peter Trudelle]

IMO, it would be better to resize the width of the tabs to fit the available
space, as is done in Windows Taskbar.  That way you can still navigate between
them with one click (you could with multiple rows too, but that would needlessly
complicate the UI)

Comment 9

[Phillip Rhodes]

I think it would be a good idea to make that choice, between scrolling the tab
bar or multiple lines of tabs, a pref.  Personally, I would prefer multiple
lines of tabs, but I can see why/where some people would prefer to scroll.  If
this could be implemented as a pref, it would be nice.

Comment 10

[Niklas Mehner]

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

Comment 11

[sairuh (rarely reading bugmail)]

spam: set your filter for "SeverusSnape" to avoid the influx of bugmail

changing QA contact of open tabbed browser bugs from blake to me. if this bug
requires a reassignment, however, feel free to change it!

Comment 12

[John Morrison]

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

Comment 13

[sairuh (rarely reading bugmail)]

clarifying summary so it's easier for me to find this bug. [see bug 101774
comment 24 and comment 25].

Comment 14

[R.K.Aa.]

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

Comment 15

[R.K.Aa.]

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

Comment 16

[m_mozilla]

FWIW, I cast my vote in the "add more rows of tabs" camp. This maintains the
easy one-click access to the tabs, and keeps them all in view. If I wanted to
use a menu to get to them, I'd have used multiple windows and the tasks menu.

The multi-row approach also wins (IMHO) over the scrolling approach in that all
tabs are immediately in view. Getting to a tab in the fourth row requires only
one click, as opposed to scrolling through "four row's worth" of tabs.

Finally, the multi-row approach encourages the user to keep their tabs under
control. As their tabs start to eat into their web-page-rendering space, they'll
eventually decide to get rid of some of their older tabs.

If scrolling *must* be introduced, I would rather see *vertical* scrolling to
show more rows of tabs, rather than *horizontal* scrolling to show more
individual tabs. Perhaps there might be a default max of four rows of tabs,
after which the user would have to scroll vertically to show the other rows of
tabs. That number 4 could be modified via prefs interface, or maybe just
manually in user.js.

The menu approach (instead of rows and/or scrolling) seems very much a UI
quick-fix... something like "our UI wasn't designed to handle your usage and so
we threw this in there to keep things from breaking" rather than a good UI design.


Possible behavior:

Use existing behavior *until* the number of tabs increases to the point that the
elipsis (...) character can no longer be rendered in the tabs. (With my font
prefs and typical browser window size, that's about 25 tabs.) At that point,
split the tabs into two rows, with the "close tab" widget alone in it's own
vertical column, still in the upper right of the tabs area (until such a time as
bug 108938 is fixed and the "X" appears on each tab). New tabs will cause tabs
to "re-wrap" to fill the two rows roughly evenly as they are added.

When the number of tabs increases to the point that the '...' is not rendered on
the tabs once more, a third row appears, and so on and so forth until the magic
number of rows is is about to be exceeded (I'd suggest 4 as a reasonable
default). At that time, the a scrollbar in introduced into the right-most
column, occupying the entire column. The "X" icon gets shifted over to the left
to make room (it still is rendered in its own column until such a time as the
above-referenced bug is fixed). Tabs are rendered to *five* rows.

Any time a new tab is added (and the tabs are re-wrapped), the tab interface
should automatically scroll to ensure that the active tab is displayed (rather
than the just-added tab, if that just-added tab is loading in the background).

New rows are still added at the same pace... when the elipsis is no longer
rendered because the rows are too crowded. This might happen at different times
for different rows, so I would suggest that the trigger be when it happens to
*any* tab in *any* row.

Special bonus annoyance: the "X" to close the currently active tab must always
hover in it's own column just to the righ of the scroll bar, and remain visible
no matter where the user scrolls vertically... until bug 108938 is fixed and
that issues goes away.

-matt

Comment 17

[timeless]

for reference wrt comment 8, the windows explorer taskbar uses scrollbars 
(perpendicular to the major axis) to get to extra rows of task buttons.
Easiest steps to reproduce: set screen res to 640x480, run 40 notepads [*you 
might have trouble running this many notepads, if so, try explorer windows], 
set taskbar to 1 row tall or 1 icon wide.

There once was a time when properties windows had < > arrows.  But I can't seem 
to date it, the version of tweakui i have running here on w2k uses multiple 
rows.

As for the add more rows camp, can someone please explain why they don't just 
open a second or third window?  I can easily arrange windows so that they're 
approximately 'rows', it's true that it takes an additional fraction of effort 
for me to see lower rows, but it mean that i can actually read the rows.

If anyone wants to spend time on a rows implementation, i'd suggest that it 
appear when the user mouses over the tabrow.  Otherwise you'll eat too much of 
the content area.  Borrowing an arbitrary rule from explorer, the number of 
rows would be limited to half the height of the content area.  Beyond that 
vertical (* if someone implements tabs on the sides instead of horizontal as we 
currently have them, then they would be horizontal) scrollbars would be 
triggered.  Clicking on a tab will of course select that tab, and also move 
that tab's row to 

If we spend any time on any implementation like this, we'll need a minimum tab 
width, i'd say 8em, but this would be set per skin and could be controlled by 
userChrome.css (for all of the bugzilla commenters here who object to whatever 
some skin uses as a default minimum width).

Comment 16 contains one falsehood.  So let's establish it quickly: Create a 
single mozilla window. size it to 8em x8em.  Create 100 tabs in that window.

Now suggest an implementation which would allow the user to see all 100 tabs at 
once, or otherwise select the desired tab without some scrolling or a second 
click. (note that i use click loosely in this demand, so a keyboard tab or 
joystick motion also count as clicks).

I'll argue that nothing suggested so far can handle the pathological case 
described above without scrolling.  In fact, no matter what we do, there will 
always be pathological cases, and this entire bug is about them. 

The fact that mozilla probably wouldn't like 100 tabs to begin with is a bug 
and shouldn't be used as an argument.  

Comment 16 is long, and i only read the beginning before commenting, it appears 
that the commenter and I might agree on some points.

This part is silly and applies for all clumsy implementations and all 
implementations in pathological cases:
Finally, the <> approach encourages the user to keep their tabs under
control. As their tabs start to eat into their <>, they'll eventually decide to 
get rid of some of their older tabs.

For trudelle's suggestion, tabs eat into the user's time.  If it takes me 
longer than X to do something maybe i'll figure out that i'm doing something 
wrong.

Ok, so i suppose i should criticize my suggestion, hrm...
1. it's confusing for things to happen just because of mouse movement.
2. you can't reach the content area. Oh whoops, you can, because i stipulated 
that tabs can't use more than 1/2 of the content.
3. if you try to aim for the top of the content area, you can accidentally 
trigger this effect.  Yep.  This goes back to my templatized version of the 
users will learn not to create too many tabs.  But in fact, there's a solution 
to this, mpt has suggested it on occasion (unfortunately i think it requires 
the mouse driver to taught about boundaries -- and this is something 
applications can't do...) basically moving your mouse out of <eg: the content 
area> should take more effort than moving it within <the content area>.

We could have a delay for showing/hiding the overflow
4. The converse, if you try to pick a tab that's on the last row you might 
accidentally move into the content area and have the tab panel rollup.  See 3.

Comment 18

[Phil Miller]

Confirming that this problem still exists in Milestone build 0.9.7 on Windows
98, incuding the scroll bar and the close tab button. In addition, the address
bar extends itself, as if the window magically tells itself that it has become
bigger as a result of too many tabs. I'm attaching a picture of this behaviour,
so you can see what I'm talking about.

Comment 19

[Phil Miller]

Attachment: What happens with more than 40 tabs open

This is with a screen resolution of 1280x960 and the Mozilla windows maximized

Comment 20

[David Hyatt]

Reassigning to new component owner.

Comment 21

[jag (Peter Annema)]

-> future, helpwanted

Comment 22

[timeless]

i'm unfuturing this and moving to UID. there's no point in leaving this bug 
with an engineer when there's no agreed upon spec.

Comment 23

[Phil Miller]

For the moment, at least, this should be left with an engineer to be fixed in some form, even if it's 
ugly, and then given to UID. There are really two problems represented in this bug: There is no 
specification of how a large number of tabs should act, and things break when there are too many 
tabs present. I think it's appropriate for jag to implement and commit the patch, just to at least 
make an ugly fix, and then UI design should take a good, hard look at it and make a decision.

Comment 24

[Peter Trudelle]

I agree with Jag, this is not serious enough to require a fix in this release
cycle, though we'd probably take a simple, safe one.  I am certain that fancy
solutions are not warranted, for instance there is no need to support dragging
links to tabs that are not visible at the start of the drag.

Comment 25

[jag (Peter Annema)]

In a window 800 pixels wide I need 25 tabs in the modern skin to begin pushing
part of the chrome out of the window. I dunno about you, but at 10 tabs I'm
starting to think about opening a new window, at 15 I've opened that new window
or have started reading those unread articles and closing some tabs. Yes, it's
not very clean, but I think I can spend my time better on more important bugs.

If someone wants to create a spec and we can agree upon it, and someone (else)
wants to implement that, that's fine, but if/when it's assigned to me again I'll
future it again for the reasons given above.

Comment 26

[Peter Trudelle]

moving back to tabbed browser/future

Comment 27

[Erik Moeller]

Please note that the bug also causes words, images etc. not to be wrapped
correctly -- they are effectively in the non-visible area of the screen, not
only for the newly opened tabs, but for ALL currently opened tabs. This results
in the weird effect that your pages become "wider" (but without a h-scrollbar)
as you open more and more tabs. Google for something and try it by opening links
til you drop. It only works on pages where words are actually wrapped at the
edge of the screen and not before.

As has been pointed out elsewhere, this is probably because of miscalculated
window width. It's a serious bug IMHO.

Comment 28

[Anthony DeRobertis]

Comment 25, 25 tabs is _nothing_. I actually run into this problem routinely.
Multiple rows sound like a good idea to me, much better than scrolling at least. 

Comment 29

[Blake Ross]

Timeless, please learn the proper meaning of the useless-UI keyword (as per the
keyword definitions page).  You have been using it improperly.

Comment 30

[marlon bishop]

multiple rows of tabs is generally considered to be ugly and poor design.
overflow management should be done with ">>" on the right end with a sub menu,
the same way as spec'd for toolbars. 

Comment 31

[Anthony DeRobertis]

I think in this case, multiple rows is much better than scrolling tabs. Just
because multiple rows of tabs are considered bad, doesn't mean scrolling rows of
tabs are't worse.

It's a lot harder, and a lot more annoying, to find a tab if you have to scroll
around (especially if you wind up scrolling back and forth) than it is to look
in the second (third, fourth, etc.) row.

Horizontal scrolling is considered bad, too.

Comment 32

[Peter Lairo]

Maybe neither multiple rows nor a scrollbar is the best solution. A dropdown
menu that lists the overflowed tabs (similar to subject lines' collumn picker in
mail/news) would display most/all tabs (=disadvantage of scrollbars) without
cluttering the screen (=disadvantage of "rows"). BTW, This solution was
suggested in comment #1, comment #6, and comment #30.

For a ridiculously large number of tabs (i.e., the menu becomes very long), we
could use the up/down scroll arrows similar to how it is in the bookmarks menu.
Alternatively, we could cap the total number of tabs at "x" (e.g., 40), but that
still may cause problems at very low resolutions.

So now we have three suggested approaches to overflowing tabs:
- Submenu listing the overflowed tabs
- Multiple tab rows
- Scroll arrows

All have now been sufficiently mentioned and argued here. I suggest to leave it
up to the developers to come up with a solution. Interested persons should
probably take the pro/con discussion to the newsgroups (please post the NG and
topic here). IMHO

Comment 33

[m_mozilla]

to facilitate such discussion by developers / UI decision-makers, how about a
tidy list of apps which would let them try out the few different options? I
don't think it's that far-fetched to compare "too many tabs" to "too many
bookmarks in personal toolbar" (with the caveat that you're probably going to
want open tabs to be even easier to reach than personal toolbar links, as tabs
are things you're actually using rather than things you tend to use frequently).

When there are too many bookmarks in the toolbar,
    OmniWeb (Mac OS X) gives multiple rows
    MSIE (Mac OS X) gives the drop-down menu
    Galleon (never used it myself) lets you scroll
    Mozilla/NN just cut off the extras

Try each of those and see which works best...
(I'm assuming nobody will decide "code two or three options and create another pref)

-matt

Comment 34

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 35

[Matthias Versen [:Matti]]

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

Comment 36

[Mikko Rantalainen]

Just wanted to comment that I don't care if I cannot see all the tabs when I
have too many tabs open, if I can still change between them with keyboard or
mouse gestures (like now), but make sure that content area is sized corretly. As
explained in comment #27 having too many tabs overflows content out of reach
right now.

If you can easily come up with a fix to simply hide tabs that don't fit
(consider it as XUL equivalent to CSS's overflow:hidden for the tab area to left
from X-button) just do it. Scrollbars and stuff can be always added later. Don't
limit the maximum number of tabs. Don't open any extra dialogs!

I can see people having many tabs opened by bookmarklets for e.g. discussion
boards that insist on showing only one comment on one page. Opening all links
from the thread listing with bookmarklet could easily spawn like 100 tabs. The
same applies to opening multiple bug reports at once after query to bugzilla.
Being unable to read content of those tabs because content is calculated too
wide is simply intolerable.

Comment 37

[Peter Trudelle]

Comment #27 should have a bug report of its own, does anyone know if it has been
filed separately?

Comment 38

[Gilles Durys]

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

Comment 39

[Alfonso Martinez]

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

Comment 40

[R.K.Aa.]

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

Comment 41

[Philip White]

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

Comment 42

[R.K.Aa.]

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

Comment 43

[R.K.Aa.]

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

Comment 44

[R.K.Aa.]

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

Comment 45

[R.K.Aa.]

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

Comment 46

[R.K.Aa.]

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

Comment 47

[David D. Kilzer (ddk)]

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

Comment 48

[David D. Kilzer (ddk)]

Bug 139272 had some UI ideas (including a sample screenshot), as well
as discussion and a screenshot when more tabs are open than will fit
in a window (which is what this bug is for).

Added dependency on Bug 126299 and add CCs from Bug 139272.

Comment 49

[R.K.Aa.]

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

Comment 50

[m_mozilla]

interface implementation aside (just please make this overflow mechanism
consistant with whatever is used for personal toolbar), I think the number of
dups  indicates that this problem is encountered by many users.

The chosen implementation should perhaps consider that.

Also, this is targeted for 1.0, but the patch is "needs work" and probably bit
rotted since Oct 2001. Should it be retargeted?

-matt

Comment 51

[Peter Trudelle]

It is targeted for a future release.

Comment 52

[Phil Miller]

I don't think it's appropriate to future this bug, when so many users are duping
it, which means that tabs is apparently widely used and known, and this bug is
widely encountered. This is definitely something that should be fixed for 1.0,
even in a blunt, not so well thought out way, then turned over to UI-Design. I'm
voting for scrolling rows of tabs, all in the tab bar, with space reserved for
the buttons to control it.

Comment 53

[Erik Goodlad]

Here are three mock-ups I've done of a method I think could be used to scroll
left to right between the open tabs (If horizontal scrolling was the course of
action taken).

Tabs overflowing to the left...
http://www.evulge.com/bugzilla/tabs_scroll_alt_01.gif
Tabs overflowing to the right...
http://www.evulge.com/bugzilla/tabs_scroll_alt_02.gif
Tabs overflowing on both sides...
http://www.evulge.com/bugzilla/tabs_scroll_alt_03.gif

When the number of tabs has exceeded the available space, two small tabs will be
displayed on the side depicting that tabs are overflowing to that particular
side.  Also, the arrow icon will change depicting it can actively be used to
scroll in a direction.

If tabs overflow to both sides, then two small tabs will be displayed on both
sides, and both arrows will be changed to active.

Notes:
1) One small tab could be used instead of two.  This would have near the same
visual effect to the user, and would also allow more real estate for the
displayed tabs.
2) If the user clicks on the small overflow tabs, the tabs could be scrolled all
the way in that direction.


My suggestion for how the focus of the active window should be effected by the
tab scrolling is this:

When the tabs are being scrolled left or right the focus of the browser window
does not change, unless the active tab is pushed out of the visible tabs, then
it would change to the next visible tab.

So if I am scrolling my tabs to the right, and the active tab falls out of the
visible tabs into the left overflow, the tab to the right of the active tab will
become the new active tab since it's still a visible tab.

Comment 54

[Phil Miller]

I don't think what you show in these pictures is the right solution to the
problem. This solution requires the user to click once for each tab moved
through. This would certainly irritate me greatly, and would probably do the
same to many, if not most, users. For example, note how older versions of
Microsoft's TweakUI displayed multiple "pages" of settings. A fixed number of
tabs were displayed at a time on screen, and left and right arrows appeared to
the right of the tabs. Each click moved the display by 1 tab. To get from the
beginning to the end required numerous clicks, which was very annoying and
time-consuming.
I propose that, when less than the number of displayable tabs are open, they all
display at once. When more than this number is opened, newer tabs will be added
to another "row" of tabs, which can be reached by clicking a button that
displays the previous or next row of tabs in the tab bar. This saves clicks when
large numbers of tabs are open, and saves screen space, because the only extra
space needed is that for the 2 necessary arrows.
The question of what to do with the active tab becoming invisible is another
issue with all of our proposals. It is possible to make a visible tab active in
place of the previous one. It would also be possible to leave the active tab
active, and not force the tab itself to be visible in the bar. The last
possibility, for which the UI Design people will crucify me for suggesting, is
to always display the active tab in the tab bar, by moving other tabs around it.
This would probably lead to massive confusion on the users' part. I suggest that
the active tab not be required to be visible at all times, as the user is
probably looking to switch tabs if he is scrolling through the tab bar. Since
this is usually the case, switching the active tab every time the bar is
scrolled would confuse and diastract the user, and probably decrease performance
noticably, particulrly on slow systems, where redrawing the browse window is a
major undertaking, in relative terms.

Comment 55

[Peter Lairo]

RE the excessively long comment #53 and comment #54: Please see comment #32!!!

_/ mozilla.org \_/ lairo.com \_/ mozillazine.org \  [ More \/] [X]
                                                    |        |_________
                                                    | vcnet.com/bms/   |
                                                    | builder.cnet.com |
                                                    | alistapart.com   |
                                                    +------------------+

Comment 56

[timeless]

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

Comment 57

[timeless]

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

Comment 58

[Aaron Kaluszka]

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

Comment 59

[Cameron Simpson]

I would like to remark that this bug's current nasty side effect,
that of making the page rendering width as wide as the (partly invisible)
tab bar, is VERY annoying. It causes the text to flow off screen (just like
tables with an overly wide banner in them, a pet annoyance of mine)
without an h-scroll.

The overly wide rendering is very annoying.
The lack of an h-scroll for the page itself in this circumstance
is a serious UI bug.

Please commit a fix of some kind, at least as far as decoupling the page with
from the tab-bar width SOON, and argue about the
argonomics later. I mean here, make a hack to make things functional
very soon, and ONLY THEN defer for later the ergonimic side.
Dysfunctional is WAY less ergonomic than "not beautifully streamlined".

Comment 60

[Peter Trudelle]

This is low impact: a tiny number of users are occasionally inconvenienced, and
there are easy workarounds and ways to prevent it.  In fact, this is a classic
'Doctor, Doctor' bug.

Comment 61

[Dominik Stadler]

We are starting to discuss here, but I also want to say that I find it very very
annoying, for me Mozilla gets unusable if I use it more than just for a few
sites. In my normal work, I encounter this bug multiple times a  day. 

That's a classic "works with a small number, but does not work with a big
number" problem. And I agree with comment #59, that we should solve first the
problem that also the HTML View gets resized, then search for a UI for
displaying more tabs.

If you look at the list of CCs and the votes, you know that a lot of people are
intereseted in this. Also around 20 duplicates are already recorded for this.

Comment 62

[Adam D. Moss]

> In fact, this is a classic 'Doctor, Doctor' bug.

Well, not entirely.  'It hurts when I do /this/' is
a valid complaint to run to your doctor with when
'this' is sticking your finger in a sucking chest wound
that shouldn't be there.  (gods, I love that phrase --
'sucking chest wound' -- I had to find a way to use it.)

Comment 63

[Peter Lairo]

> In fact, this is a classic 'Doctor, Doctor' bug.

No, because this bug is VERY noticable in mail/news nearly every time I either
receive mails with attachments or with long e-mail addresses (very _unlike_ a
'sucking chest wound', because it is more common and more painful ;) )

Comment 64

[Hixie (not reading bugmail)]

Uh, this bug has nothing to do with mail...

Comment 65

[Peter Lairo]

> Uh, this bug has nothing to do with mail...

Egads, you're right. I was talking about bug 91662, which *is* "more common and
more painful".

Comment 66

[Markus Långström]

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

Comment 67

[Andrew Simmonds]

When a menu for example, bookmarks is too big, it's scrollable up/down.
let me ask this question:
why cant that technology simply be implemented for the tabs for when there are
too many?

surely even a simple hack port of that code would be better than the current
situation.

Comment 68

[Bill Nottingham]

"In fact, this is a classic 'Doctor, Doctor' bug."

Doctor, doctor! I expected the feature to actually be implemented sanely!

Are you seriously saying that users should *expect* there to be brokenness?

Comment 69

[Matthias Versen [:Matti]]

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

Comment 70

[Peter Trudelle]

I'm saying this is more like a self-inflicted paper cut. If you don't like the
results, don't do it.  We have hundreds of bugs that are orders of magnitude
higher impact; this one currently isn't worth the time we'd have to spend
reviewing, let alone fixing.  

Comment 71

[Bill Nottingham]

Well, an attitude that *complains* about users reporting bugs in mis-implemented
features is not really a good way to get user share. If you don't feel it's
worth fixing the feature, then take it out.

Comment 72

[John Levon]

comment 71: who was complaining ? Certainly not Trudelle: he was     
giving reasons it was low impact. And it /is/ low impact, you have
to create an obscene number of tabs, and there's a very simple workaround.

I don't see anybody saying this shouldn't be fixed some day. Which
makes me wonder what you're talking about ... perhaps
you just completely failed to read comment 70 ?

(Besides the bug is not an appropriate place to whine)

Comment 73

[Bill Nottingham]

I find the statement:

"A tiny number of users are occasionally inconvenienced"

on a bug that already has ~20 duplicates odd, and 

"This bug currently isn't even worth spending the time reviewing, let alone fixing"

to be insulting. Maybe that's just me.

Comment 74

[Peter Trudelle]

A large part of my job right now is to triage Navigator bugs to identify the
ones that must be fixed for MachV, and assign scarce resources to fix them. 
This bug is low impact, and can easily wait until after MachV.  I appreciate
people reporting defects, but I must say I get very tired of being expected to
reverse nearly every triage decision just because a few people disagree.  Every
feature has bugs, and I find it very odd that you think we should pull such a
popular feature because of this bug.  If we took the time to fix this level of
bug, we would not finish on time, and the people paying for most of this
development work might decide that their money is better spent elsewhere.  I'm
certainly not intending to insult anyone, and I'm sorry that my comments made
you feel that way.

Comment 75

[Hixie (not reading bugmail)]

Anybody whe wishes to fix this bug is, of course, welcome to attach a patch. I
will personally see that the patch receives reviews and will check it in for the
author if necessary.

Comment 76

[Winnie]

I vote for multiple rows.

Comment 77

[Peter Trudelle]

Multiple rows would add a lot more chrome/complexity, take away from the
precious vertical content area, require a further decision on when to stop
shrinking and open a new row, and still leave the same problem: how to handle
overflow when the solution runs out.  In this case, that might not be until the
content area fills up.  I hope that seems absurd to most of you, but  the idea
of having even a couple of dozen tabs open in one window seems absurd to me, yet
I feel sure one or more contributors would file bugs on the overflow of multiple
rows, asking that they scroll or something.  
->1.2, to get this on the radar for a point release.
->ADT4, very low impact for target users.

Comment 78

[Phil Miller]

It's great that this bug has finally been targeted to a specific future release.
However, I'd like to protest the statement and associated ADT rating that this
bug has low user impact. It has been duped 21 times so far, and causes a nasty
side-effect. As has been stated by others, I don't really care so much that some
tabs become invisible, but content and the vertical scrollbar "falling off the
screen" is unacceptable.
If we want to separate between the UI isue of what to do when there are too many
tabs and the problem resulting in content, the v-scroll bar, and the tab-close
button disappearing, bug 101774 should be reopened to deal with the latter
issue, and the problem of how to make it usable and pretty looking can be dealt
with here.

Comment 79

[Lee]

A horzontal scroll bar, as suggested above , would be a good idea.
As more and more people use tabbed browsing, this bug might give a bad 
impression on mozilla.As Netscape is putting tabbed browsing as one of the main 
enhancements in NS7, This bug should be given higer priority.

It would be nice if the excess tabs opened in a new window.
eg: if no of tabs >14 then, redirect it to new window.
Every new link after that should open in window no 2.
if it reaches 28 then open window no 3. etc...

However, a scrollbar would do for now.
and yeah, this IS a VERY annoying bug for me.

Comment 80

[Hixie (not reading bugmail)]

The UI that marlon recommended is:
     _________________   ______________   _________________    ____
   _/ mozilla.org [X] \_/_BBC_News_[X]_\_/_mozillaZine_[X]_\__[ >> ]_
  |                                                | Bugzilla      | |
  |                                                | W3C Home Page | |
  |                                                | Bug 1777      | |
  |                                                '---------------' |
  |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

...and is what we shall be using.

Comment 81

[Adam D. Moss]

Sounds nice.

Comment 82

[timeless]

     _________________   ______________   _________________    ____ 
   _/ mozilla.org [X] \_/_BBC_News_[X]_\_/_mozillaZine_[X]_\__[ >> ]_ 
  |                                                | Bugzilla      | | 
  |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\| 
  |________________________________________________| W3C Home Page |_|
                                                   |       vv      |
                                                   '---------------'
What happens when you hit the bottom of the window or screen? (and which do we 
hit?)
my guess is that you get vertical scroll arrows.
Supposing I'm 3 lines from the bottom of the screen, do we make the menu very 
short, or do we expand up towards the top of the _______________  Screen?
                                                |       ^^      | 
                                                |/\/\/\/\/\/\/\/| 
 File_________________ Go______________Help____ | Pathological  |
   _/ mozilla.org [X] \_/_BBC_News_[X]_\_/[ >> || Silly         |
  |                                            || Bugzilla      | 
  |                                            || Bug 1777      | 
  |____________________________________________|| W3C Home Page |
                                                |       vv      |
                                                '---------------'
Keep in mind, no matter what you do, you have to expect pathological users, 
because they're the only kind :)

Comment 83

[Adam D. Moss]

The existing scrolly-pulldown-menu widget already
deals with these cases, and I expect that's what
would be used.

Comment 84

[Peter Trudelle]

"shall be"?  I must have missed the memo announcing Hixie's dictatorship.  ;-)

The '>>' menu solution for bar overflow is the defacto standard on Windows, and
I'd also support using it here. As Adam points out, the standard way of dealing
with overflow in the menu is to have it scroll, like other menus that can grow.  

However, adding close buttons on each tab (which is what I assume is meant by
the Xs in your diagram) is something we decided against long ago, and should not
be part of this discussion.

Comment 85

[Hixie (not reading bugmail)]

timeless: same as we do for the back button.

Ignore the [X]s in my diagram, they are unrelated to this bug.

The "we shall" in my comment was based on the module owner's comments to me to
the effect that marlon was to decide this. I am merely the messenger...

Comment 86

[j]

I like the windows overflow method (i.e. using ">>"). I would also like to
suggest an improvement to the windows overflow method. When there is, for
example, 50 tabs in the overflow dropdown menu, how about splitting them up in
increments of 10 (or 20 or whatever the consensus is)? every 10 tabs would be
grouped in a submenu. so the excess 1-10 tabs would be in a submenu called
"extra row 1" (or something to that effect), 11-20 in "extra row 2". etc.  The
same solution can be used for personal toolbar overflow handling as well. Access
to tabs/bookmarks would be fairly quick - a click and a select. here's an
illustration of how it would look. 

     _________________   ______________   _________________    ____
   _/ mozilla.org [X] \_/_BBC_News_[X]_\_/_mozillaZine_[X]_\__[ >> ]_________
  |                                                | Extra Row 1 > -|extra 1 |
  |                                                | Extra Row 2 > ||extra 2 |
  |                                                | Extra Row 3 > ||extra 3 |
  |                                                '---------------'|extra 4 |
  |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|extra 5 |
                                                                    |extra 6 | 
                                                                    |extra 7 | 
                                                                    |extra 8 | 
                                                                    |extra 9 | 
                                                                    |extra 10| 
                                                                    ----------

Comment 87

[j]

follow up to my previous post. if there is an odd number of extra overflowing
tabs/bookmarks (13 for example), the first 3 would display in the dropdown menu
and the next 10 grouped in a submenu under the first 3. 

Comment 88

[timeless]

to be clear, i only used hixie's diagram as a basis so any [x]'s were based on
his thing, i don't care about them. I was only trying to make sure we were clear
on the pathological case.

j: trees might make sense, but what happens when you need to overflow your
parent level?
[supppose the screen has vertical room for 8 menuitems and you have 470 tabs (so
8*8+6displayed+400 which need a display mechanism), hrm this case isn't really
pathological yet.] -- The big problem with treeing is that they don't make
sense. Because unless there's some logic (and there isn't) that the user can
understand in placement and movement of tabs into your tree, the user will be
completely baffled when tabs change branches (which would happen if the user
closes tabs).  Essentially due to the linear nature of tabs you're stuck not
being able to make a useful improvement on linear display.

fwiw the old windows overflow mechanism for fonts/bookmarks menus of generating
side by side menus is somewhat advantageous at the expense of screen realestate
and surprise. (Surprise because that layout is almost entirely extinct)

Trudelle: re hixie's dictatorship memo, it's been in quite a few bugs recently,
I'm not quite sure how you could have missed it. ;-(

Comment 89

[Peter Trudelle]

Design for pathological cases is wasted effort at best, and can degrade
usability for common scenarios. There is no point in trying to make absurd usage
cases like dozens of tabs easy to use. A single, scrolling overflow menu is
quite sufficient here.

Comment 90

[Peter Lairo]

> A single, scrolling overflow menu is quite sufficient here.

By that I hope you mean this:
      ______________   ____________   ______________    ____ 
(A) _/ mozilla.org  \_/__Q3A_maps__\_/_mozillaZine__\__[ \/ ]
   |                                        *---------------||
   | Mozilla is not for end users - HUH?    | Bugzilla      ||
   |________________________________________| W3C Home Page ||
                                            | DOOM III mods |
                                            |      vvv      |
                                            '---------------'
And NOT this:
      ______________   ____________   ______________    ____   ____
(B) _/ mozilla.org  \_/_NPR_Radio__\_/_mozillaZine__\__[_<<_]_[_>>_]

Comment 91

[Peter Trudelle]

Well, it should be a menu, not a scrolling toolbar, but appear as '>>', not 'V'.

Comment 92

[Hixie (not reading bugmail)]

j: no, you just do the same as when any other menu in Mozilla overflows, you
make it scroll up and down...

Comment 93

[Mikko Virkkilä]

I was very surprised to see this bug tagged as Severity: minor. For users with
small screens this is a major usability problem (and you don't have to open more
than a few tabs to see it).

I used tabbed browsing almost exclusivly (well, with the exeption of a few
cases, caused by bugs) because it lets me hide my toolbar and quickly change
between sites. It also doesn't clutter my desktop. Since I open a lot of tabs in
the background (shift+middle-click), as not to brake my stream of thought (like
adding stuff to a to-do list), it is extremely annoying to note I can no longer
close the tabs (well, now I am getting used to ctrl+w to fix that). 

I really like the layout (simplicity) of post 90, and I hope it get's
incorporated in to mozilla soon. I would also like to point out that a menu pops
up when you click on a tab with the right button. I would like to see this in
the dropdown menu too.

Comment 94

[Peter Lairo]

How about:
     ______________   ____________   ______________
   _/ mozilla.org  \_/__Q3A_maps__\_/_mozillaZine__\__[More Tabs \/ ]

PT: Why are you suggesting ">>" instead of "\/"? The menu will drop "down"
(also, there will unlikely be any space to the right {screen edge} to show the
menu that would make ">>" make sense), and the Sidebar "Tabs" button also has
"\/" (in Modern theme).

PS. Will the "More Tabs" button be invisible when there is no overflow, or will
it be grayed out?

Comment 95

[Peter Trudelle]

Peter: I didn't suggest it, our UE Designer did.  I just agreed with it because
it is the standard toolbar overflow mechanism on Windows.  The triangle is
invariably associated with something else, usually a menu title, but the ">>"
stands on its own, without requiring any space-sucking "More Tabs". I think it
should only be visible when there is overflow. I don't see why we'd consider a
homegrown solution when a defacto-standard pattern exists.

Comment 96

[Robert Wall]

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

Comment 97

[[e-mail]]

Attachment: lame kludge

All this does is to ensure that the extra tabs don't push the [X] and other
chrome off the edge of the earth.

Comment 98

[[e-mail]]

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

Comment 99

[Aaron Kaluszka]

Comment on attachment 86404 [details] [diff] [review]
lame kludge

This temporary kludge is better than nothing.  I don't know if I have the right
to do this, but r=ask

Comment 100

[Peter Lairo]

What does this "kludge" do?

Could it also be used to fix the even more annoying bug 91662 "Long strings in
mail or news header cause scroll bars and attachment window to disappear, making
message unreadable"?

Comment 101

[Aaron Kaluszka]

It changes the tab container so that when the tabs overflow, they are cropped on
the right-hand side, instead of growing the container and pushing the rest of
the UI off screen.  Technically it does fix the bug.  The same concept might be
able to be applied to the mail window problem.

Comment 102

[Peter Trudelle]

r=ask has no bearing on checkin, Peter Annema is considered the module owner here.

Comment 103

[John Morrison]

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

Comment 104

[Aaron Kaluszka]

Comment on attachment 86404 [details] [diff] [review]
lame kludge

well I tried fwiw :-(

Comment 105

[dave]

I vote for scrolling tabs, as per Comment #53 From Erik Goodlad  or a drop down
menu. Scrolling has the bonus of supporting an 'unlimited' number of tabs. 
Extra kudos if the scrolling is smooth rather than jumping a tab at a time.

Comment 106

[Matthias Versen [:Matti]]

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

Comment 107

[[e-mail]]

Attachment: new kludge

Apparently jag's eyesight is better than mine (although possibly I was too
tired) and the previous patch bitrotted anyway.

Comment 108

[Bill Mason]

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

Comment 109

[jag (Peter Annema)]

Comment on attachment 87490 [details] [diff] [review]
new kludge

You've tested this to make sure there's no visual and functional difference
(other than the intended) in both modern and classic?

Can you also update the tabbox binding that's in the mac classic skin's
general.xml (I think)?

Comment 110

[[e-mail]]

Attachment: Added globalBindings.xml for mac

jag, I haven't noticed any problems with this patch in Modern or Classic.

Comment 111

[jag (Peter Annema)]

Comment on attachment 90073 [details] [diff] [review]
Added globalBindings.xml for mac

sr=jag

Comment 112

[[e-mail]]

Fix was checked in by bz.

Comment 113

[timeless]

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

Comment 114

[Robert Kaiser]

Comment on attachment 90073 [details] [diff] [review]
Added globalBindings.xml for mac

>Index: themes/classic/global/mac/globalBindings.xml

[...]

>+      <xul:box flex="1" style="min-width: 1px;">
>+        <children/>
>+        <xul:spacer class="tabs-right" flex="1"/>
>+      </xul:hbox>

er, sorry, just came across that, do you really want to close a box with an
hbox tag?

This should either be an hbox from the beginning or closed correctly as a
box...

Comment 115

[jag (Peter Annema)]

Typo has been fixed.

Is there a new bug yet on having some overflow control?

Comment 116

[Lee]

Is this fix part of current builds ?.
Also,How long does is usually take, for a fix to make it to a nightly build.

Comment 117

[[e-mail]]

Comment on attachment 90073 [details] [diff] [review]
Added globalBindings.xml for mac

Apologies for the typo, I should have cut & pasted the xul from the windows
part of the patch instead of attempting to retype it from memory :-(

Comment 118

[Hixie (not reading bugmail)]

What's the bug # for the scrolling mechanism UI?

Comment 119

[Jason Bassford]

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

Comment 120

[Gilles Durys]

Ian: bug 155325 ?

Comment 121

[Hixie (not reading bugmail)]

cheers

Comment 122

[R.K.Aa.]

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

Comment 123

[Pratik]

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

Comment 124

[Robert Tolliver]

RE: <a href=http://bugzilla.mozilla.org/show_bug.cgi?id=106927#c53>comment 53</a>

I like this idea, but instead of having arrows why not click the partial tabs to
move to the next tab (or screen) as shown:

* [google][Bug 106...][Bug List][MozDev]]] x
                                        ^
                        click here to scroll to next tab(or next screen of tabs)

Comment 125

[Robert Tolliver]

RE: <a href=http://bugzilla.mozilla.org/show_bug.cgi?id=106927#c53>comment 53</a>

I like this idea, but instead of having arrows why not click the partial tabs to
move to the next tab (or screen) as shown:

* [google][Bug 106...][Bug List][MozDev]]] x
                                        ^
                        click here to scroll to next tab(or next screen of tabs)