From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 BuildID: 2002052306 When lots of tabs are open (this is not very many on low-resolution screens with windows not full-screen), only the leftmost N tabs are accessible. There needs to be some way to access the rest of the tabs (other than closing the leftmost N tabs). Reproducible: Always Steps to Reproduce: 1. Hit Ctrl-T ``many'' times. (If you have a low-resolution screen, and/or you shrink the browser window to a narrow column, the ``problem'' starts to occur after only 10 or so tabs are opened). 2. Type a web address into the address bar in the current (``rightmost'') tab. 3. Click the leftmost tab to activate it. 4. Try to activate the ``rightmost'' tab. Actual Results: Only the leftmost N tabs are accessible, unless I close some of them. Expected Results: Umm... good question. Some ideas were floated in bug 106927. Bug 106927 is a plea for fixing a bug ASAP: the right side scroll bar disappearing. This request for enhancement is a place for discussing how the tabs should be displayed in the pathological case of the user opening too many tabs to view at once, and/or the user shrinking the window too narrow to show all the tabs. -- David Cary

I always thought the best idea was horizontal scrolling once the tabs overflowed.

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

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

The UI people suggested we use a drop down menu at the end of the tab bar if there are too many tabs: _____________ __________ _____________ ____________ ____ _N_/_mozilla.org_\_/_BBC_News_\_/_mozillaZine_\_/ nawl: Ad...\_[ >> ]_X______ | | ln.hixie.ch | | N A W L | Bug 155325 | | |:Bug:List::::| | « Do you approve of violence, Miss Boon? | Main '----------|\-' | | \ |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

i'd like to propose worksforme, since you can in fact access those tabs using the keyboard ;-) -- ctrl-pagedown. but seriously, do we need more bugs for this?

the drop-down menu is a good idea(!); and it gave me another: what about grouping tabs by domain/IP if more then one is opened per domain ______________ ______________ _________________ ________ [N] [ Bugzilla.Moz ] / www.site.com \ [ www.search.ch ] [ >> ] [X] | | Bug 148293 | | search results | | google | | | | Bug 155325 | | search query | | other | | | | Query ... ¦ '----------------' | tabs | | | '-------------' '--------' | | Google | | | | | |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

comment on comment #5: you're right, you can access them with the keyboard, but... ... it is not user-friendly ... it doesnt look really nice recently a colleague told me after using mozilla on this computer (she is IE user), that mozilla works like every browser do (she is not an 'computer-freak', just a user) and the only good thing she remarked were TABS => Tabs are a strength in mozilla and should be enhanced wherever it is able to do so - normal users like such features (no amateur would ever ask if something is opensource, has DOM-support, ... - an amateur would ask how something other can enhance his/her work on the computer) => Me myself, i like also to search for a method how to enhance everydays tasks, like browsing on the web

A few things: As an overall comment, I'd like to see whatever solution we come up with "kick in" sooner than it would if based on current behaviour. At the moment, the width for the tabs gets horribly cramped before the UI stops showing any more. I don't know if this is hardcoded or based on each computer's screen resolution, but get overflow happening at 40 tabs. I'd rather have our overlow take affect about halfway through what it does right now, 15 or 20 tabs, so that tabs widths and the UI both remain somewhat usable. The dropdown menu might be a good idea. (I can't really decide if, personally, I'd rather scrollbars or a dropdown menu.) I certainly think that we should NOT be grouping anything by IP or any other category in the dropdown box alone. Such grouping should be proposed in a separate bug and would, I think, affect all tabs. (I'm not in favour of it in general, but that's another issue.) Thinking in terms of extreme cases - many, many tabs - I think a dropdown box should offer the following kind of entries: 1-20 21-40 41-60 61-80 81-100 And so on, rather than a single entry per tab with its title. The range would, of course, be based on how many tabs have been determined to display onscreen at once prior to reflow. That way, you jump from one "screen group" to the next. If you use single tabs and titles, you'd have to make the width of the dropdown box quite large to accomodate tab titles. This way, the width remains pretty constant and takes up less space.

Just looked at grouping by tabs comment 6 again. The picture shows what looks like tabs within tabs. (There are multiple tab entries in the "active" tab bar in addition to the dropdown list itself.) That behaviour has already been marked as WONTFIX in other bugs.

you're right: there must be a 'minimal tab size' apropos a menu like this: 1-20 21-40 41-60 61-80 it is of course a good idea, but there is one problem: when someone uses 80 Tabs - how can he/she find a tab in this 'chaos'? The d-d menu should help out if a certain 'minimal tab size' is fallen short and the titles cannot be read any longer the grouping by IP or something else is only a good idea for people who are on the extreme (e.g. more than 30 tabs in one window) where this sorting give somebody an idea what is open and where it can be found about the 'too long titles in the [ >> ] tab': you are right, but what about using a 'maximal menu size' and if the title doesnt get in, using instead of 'the title of this page is too long' something like 'the title of this pa... ' -> the webmasters are wrong by making such too long titles - but in most cases the needed information is in the first 20 letters

'picture' from comment #6 as it should be when a page is visited on the internet [N] [ Bug 155325 ] / www.site.com \ [ www.search.ch ] [ >> ] [X] | ^ | | ¦ active tab | | | | | | Bugzilla Bug 155325 | | | | Very many TABs UI not fully developed | | | | | | | |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

> when someone uses 80 Tabs - how can he/she find a tab in this 'chaos'? Good question. Regardless of *what* solution we implement, I think the user with that many tabs open would always have difficulty locating anything. I don't think displaying the tab names would be much more help than the tab ranges for somebody who's opened up that many tabs. In fact it might even be more confusing. Anyone who's got themselves in a position of having 80 tabs open isn't likely to even be aware of any of the tab titles - they would have opened up a huge series of links from a reference page. Frankly, I don't think that they'd ever want to find a *specific* tab in such a case (they'd just want to scroll through them in general), nor would they know its title if they did. The only thing they *might* know would be its general position in "the pack". With so many tabs open, the only "useful" thing to do, IMHO, would be to reposition the active tab bar "viewpoint" to various positions (at the end, in the middle, etc.) and, with this result in mind, a numerical range would better serve. If we just use names, and I have 80 tabs open (somebody please shoot me if I ever do that) and I want to get to around the 3rd quarter section of tabs, it would much easier to pick out "41-60" than it would be to scroll down until I got to what I estimated was that area. > The d-d menu should help out if a certain 'minimal tab size' > is fallen short and the titles cannot be read any longer Are you suggesting that we implement the dropdown menu regardless of whether or not we've overflowed? I had thought that our fix would only take affect in the event of an overflow... > the grouping by IP or something else is only a good idea > for people who are on the extreme I would only find that more confusing than anything else. (Particularly if I wanted to get to the "3rd quarter" range of tabs - how could I do that if they weren't sorted in sequence?) We want to implement something simple and easy to navigate with, not something that would require much thought on the part of the programmer or user. This should be a very basic fix.

I'm not sure this has been suggested yet - it doesn't seem like it's been mentioned in this discussion yet: What about just arranging the tabs vertically like Opera? Arranging them vertically allows for many more tabs to be visible at any one time, and they can all be readable. As far as what to do when too many tabs are displayed (whether vertical or horizontal), I'll let you guys worry about that. I just think that much better economy is acheived with vertical display. Are there good reasons why this can't be done? I'm surprised to be the first person to mention it, especially since Opera does it so efficiently. Jeff

I think that what we're looking for here is a solution that won't rely on the number of tabs you're using being finite. (Or, rather, a solution that only works up to X.) Whatever we come up with should work, in theory, with hundreds or thousands of tabs. While arranging tabs vertically rather than horizontally may increase the possible number of tabs displayed prior to overflow by some degree, it won't actually solve the problem in the end.

******COMMENT POSTERS: READ THIS******** Now that I have your attention... A lot of what is being discussed here has been covered a lot in bug 106927. I recommend that you (whoever is desiring to post a comment) 1) read through the discussion in bug 106927, 2) read through the discussion in this bug, and 3) if you still have something that hasn't been said before, take the discussion to news://news.mozilla.org/ah4od3$k4o1@ripley.netscape.com . To reiterate, bugzilla is not the place to discuss UI enhancements (even though it is [ab]used for that frequently). Once a tenable solution has been worked out in the newsgroups (preferably with agreement from some mozilla UI gurus), come back here with a design recommendation.

Sorry for the spam... I forgot to mention: That message is in netscape.public.mozilla.ui. The subject is "Tabbed Browsing: Gracefully handling tab overflow".

Based on discussion in the UI newsgroup, and in reading through discussion in bug 106297, it SEEMS to me as if more people than not want to have multiple tab rows. The solution to overflow in *that* situation is to have a vertical scrollbar that scrolls up/down through the various tab rows that become available. The solution as to how many rows to show, is solved by having a resizable tab row "window". Multiple rows seems to be the majority opinion, and vertical scrolling and window resizing are good methods of addressing problems related to that approach. Obviously, however, there will never be 100% agreement on a solution here, so there will always be somebody who is unhappy. It's not clear how to proceed from here. That said, I'm sure that everybody WOULD agree that any of the discussed methods of addressing overlow would be better than what we have at present. Perhaps we should just pick the method that's easiest and quickest to implement from a programming standpoint, close this bug, and then deal with other approaches/issues once we actually do have at least SOME solution in place.

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

Here is one simple solution using a drop down menu at the end of the tab bar if there are too many tabs. (The patching might not work properly with Classic skin because of a bug in PatchMaker. )

Grouping tabs (comment #6) is a capital idea, but you can still have too many tabs so different there will be more groups that you can display. So it can only be an additional feature. Drop down menu (comment #4) will become confusing when I reactive a tab from the drop down menu and hence change the order of the tabs. Plus there will be a lot of problems with manual tab reordering. I suggest a solution similar to comment <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=106927#c53">#53</a> (with screenshots!) of bug #106927: [N] [|<] [<<] [<] [Tab k] [Tab k+1] [Tab k+2] [>] [>>] [>|] [X] [>] should make the tab row move one to the right: [N] [|<] [<<] [<] [Tab k+1] [Tab k+2] [Tab k+3] [>] [>>] [>|] [X] [>>] should make the tab row move "one page" to the right: [N] [|<] [<<] [<] [Tab k+3] [Tab k+4] [Tab k+5] [>] [>>] [>|] [X] [>|] should make the tab row move to the right end: [N] [|<] [<<] [<] [Tab n-2] [Tab n-1] [Tab n] [X] and [|<], [<<], [<] should of couse do the same in the left direction. Then there is still the tab reordering issue. In this case, just drag and drop, and when you drag over the [>>], for example, the tab row should keep going "one page" to the right, until you see the place where you want to drop, and drop it. I know, I know, this would not be easy to realize... But you *are* all looking for a challenge, right?

I think we should not have many new buttons to select tabs, it makes the UI too complicated. The comment #4 is a simple and working solution. This patch is for that. (I have currently 34 tabs of which 10 are visible and everything is working just fine.) Could we use this solution for now and if someone makes something better then remove this?

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

I agree with issue 1 . (10 is just usually working well - even with low resolutions.) Issue 2: the tab is set collapsed because this way the new tab is really invisible when needed. And if it shouldn't be collapsed, then this.mTabContainer.updateVisibleTabs() makes it to show up. These things should not be here, but because tabbrowser does not use tabbox in a right way, the hacks are needed. Issue 4: (I don't quite understand what you mean about unreadable tab labels.) I know this patch might not be flexible enough for future, but the tabbrowser's code is a bit messed so I believe it really should be (at least partly) rewritten. I was trying to make pretty small but still working fix for this simple and annoying problem but I do understand the critic.

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

My $0.02 on Mozilla's tabbed UI: * Tab width should be variable, and should use a width based on the length of page title, limited to some configurable length (e.g. 30 characters). [currently a tab's title uses a proportion of the available width, _or_ a width of approximately 35 characters, whichever is less, meaning that all tabs in a window have the same width. This commonly results in too space much for pages with short titles, and truncated titles for pages with longer titles] _______ _________________________________ _________ __/ Short \_/ This is a quite long page title \_/ Short-2 \_____________ | | | | |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\| * Tabs should occur on multiple vertical lines, if necessary. [Precedent with Opera + IE add-ons. Some even have a choice between a single line of tabs that can be scrolled, or displaying multiple lines to handle overflow; Having tried using both methods, using multiple lines to me (and others) is more pleasant to use and feels like a more powerful interface than a single scrollable line] * Tabs should include a LED load status. [Currently tabs are either loaded or loading; Two or three more intermediate steps would be good, sort of like a mini version of a tab's page load indicator that displays in the status bar. There's an example of a 3-tier traffic light system for tab status shown in a dialog box in point 22 of http://multizilla.mozdev.org/features.html ; Around two more tiers to indicate various states of 'pending' would be ideal]

I suspect that variable width tabs will end up being a lose in most cases. I reported a bug in Chimera relating to slowdowns with many tabs (bug 156607). From the commentary on that bug, it appears that this is due to Apple's variable width code. Accepted that Apple's code may be sub-optimal, but it suggests to me that it may not be as easy as it seems at first glance. The rest makes sense to me, and would probably be relatively cheap.

> Tab width should be variable That's bug 126611. > Tabs should include a LED load status. [Currently tabs > are either loaded or loading; I think that's sufficient. Besides, that should be an enhancement request in a different bug. > Tabs should occur on multiple vertical lines That's my personal preference, but I'm more in favour of a simple dropdown list or scrollbar for now. It's the simplest to accomplish and can address the immediate issue of the lack of a non-keyboard method of accessing overflow tabs. Further refinement can come later. I'm worried that a lot of debate here will simply hinder the progress of *any* solution.

> * Tabs should include a LED load status. [Currently tabs are either loaded or > loading; Two or three more intermediate steps would be good, sort of like a mini > version of a tab's page load indicator that displays in the status bar. See bug #133053

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

Comment from bug 163318 +-------+-------+-------+-------+ | tab 1 | tab 2 | tab 3 | tab 4 | +-------+-------+-------+-------+ | tab 5 | tab 6 | actual| tab 8 | +-------+-------+ +-------+ | actual tab content | +-------+-------+-------+-------+ | tab 5 | tab 6 | tab 7 | tab 8 | +-------+-------+-------+-------+ | actual| tab 2 | tab 3 | tab 4 | +-------+-------+ +-------+ | actual tab content |

Let me just take the previous comment and clarify something. Whenever the idea of multiple lines of tabs comes up, the one biggest argument against using it is because people don't like the idea of tabs "jumping" all over the place. I think that this is a mistaken idea of what would happen in such a circumstance because of the way that Microsoft has implemented multiple lines of tabs in their own interface. With Microsoft, when you click on a tab, that tab row suddenly becomes the bottom tab row, and everything does jump around. I think that behaviour is awful and have always hated it. I would not be impressed if multiple tab rows were adopted by Mozilla and implemented the same way - but there is no reason for a solution here to incorporate that faulty behaviour. Comment 31 again represents the faulty jumping behaviour that seems to be the biggest complaint against using multiple tab rows. Here's an example of better, non-jumping behaviour: +-------+-------+-------+-------+ +-------+-------+-------+-------+ | 1 | [ 2 ] | 3 | 4 | | 1 | 2 | 3 | 4 | +-------+-------+-------+-------+ +-------+-------+-------+-------+ | 5 | 6 | 7 | 8 | | 5 | 6 | [ 7 ] | 8 | +-------+-------+-------+-------+ +-------+-------+-------+-------+ | Content | | Content | Tab 2 clicked, content displayed. Tab 7 clicked, content displayed. There is no reason why the tab rows have to jump around. Leave them exactly as they are and simply change the display portion. This then makes the tab rows behave more like buttons on a "control panel", with the content being the "display screen".

Yes but this way you loose the methaphore of a phisical archive, with sheets which have a tab on one side... top row tabs wouln't be connected to the page. Anyway, no problem for me, one will do as does the other ;)

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

2 problems: Default tab doesn't work, and context menu doesn't work :-(

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

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

I am proposing the idea of tab inheritance. A second row of tabs should be opened underneath the existing tab the window was opened from, creating a tree like layout. This would prevent so many tabs from being opened, and allow easier navigation between tabs.

shwag: That has been propsed before (bug #146677) and WONTFIXed.

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

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

People! Please, do something with this bug! This is MOST irritating thing in such a perfect browser. (as well as lack of changing tabs order) At least add scrolling to the next/previous with arrow buttons as it done in NetCaptor or CrazyBrowser. PLEASE! p.s. sorry for such message, but now we already have v 1.3 alpha - and still nothing :(

I'd like to add my vote for this to be fixed. I think having a dropdown on the right-hand-side is an excellent idea. It would look almost Identical to what you get when you click on the Bookmarks tab. I don't think scrolling is particulary (sp?) useful as you can't see what your scrolling anyway (All you see is a small tab with an icon). I love using tabbed browsing (I deleted my IE shortcuts after one day of using it). This is the only outstanding UI issue from a perfect tabbing experience. IMHO. :)

> I don't think scrolling is particulary (sp?) useful as you can't see > what your scrolling anyway (All you see is a small tab with an icon). First of all, I'm going to hope that when this bug is fixed, the maximum number of tabs before overflow is going to be tweaked. There should be about half as many as there are currently. If this is the case, then scrolling would work just fine. Secondly, I don't really care which of the many suggestions already proposed here gets implemented - so long as *something* gets implemented. Anything at all is better than what we have at present - which is just awful for those of use who frequently get to an overflow situation.

Start lobbing on http://mozdev.org/bugs/show_bug.cgi?id=3042 for a very good temporary workaround that could appear much sooner :) Mozgest is a neat workaround for this problem already. (you don't see the "current tab" but you can switch between tabs that aren't visible) http://optimoz.mozdev.org/gestures/index.html

I appreciate the sentiment, and another alternative is Piro's tab extensions at http://white.sakura.ne.jp/~piro/xul/_tabextensions.html, but this bug is concerned with something that should be native to Mozilla. (Otherwise, this bug wouldn't be here. <grin>)

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

Crazy Browser (An MSIE front end for Windows) has an interesting tabbed browsing feature that stacks tabs on top of each other when the titles get long. Currently Mozilla has tabs side by side, which can be diffcult to read after more than eight are used. I read a comment on Slashdot which echoed this gripe. Crazy Browser has this feature disabled. If Mozilla adopts this feature, we should follow this course. I also suggest that this feature should be used only when the user has 12 tabs open.

I think Crazy Browser (MSIE frontend) has the answer we are loking for.

To everybody posting here: Please read through all of the previous comments before making one of your own with a "new" suggestion. Odds are, it's already been suggested. Also, I believe that there should be NO further debate in this bug. Any comments should be for the submission of patches, and technical discussions of patches. Speaking of which, what is the status of the patches already submitted? Do any of them still function, or has the code suffered from bit-rot by now? Also, is the 2nd patch in the list obsoleted by the 3rd? If so, it should be marked as such.

Nav triage team: nsbeta1-

I have seen some sort of fix for this in a build around 1.1, where a set of arrows apeared on the right. In 1.3 it seems to have disappeared and again, many tabs can't be accessed. The above shows a 800x600 screen with about 50 tabs. (I was opening many messages in a mailing list archive thread...)

I just applied Neil's attachment 98482 [details] [diff] [review] to my 3/27-04 build of Mozilla under XP and it worked, however there are a couple of issues that would still need to be resolved with it (in addition to the known problems he mentions in comment 35). 1. I don't like how the scrolling takes place on mouseover rather than click. It makes it difficult to control the "horizontal movement" of the tab bar. It should be modified so that left and right scrolling only takes place when the scroll arrow is explicitly clicked on. 2. There are left-most and right-most tab "artifacts" being shown. In other words, tabs that are only being partially displayed. The width of the tab bar, in consideration with all of the screen elements, including the scroll arrows, needs to be re-worked so that there are never any such artifacts. You should see the new tab button, a left scrollbar, a row of *complete* tabs, a right scrollbar, and the tab close button. Point 2 is important for those people, such as myself, who have used userChrome.css to modify the minimum width of tabs so that those that are shown are actually usable when overflow occurs. For example, I now overflow at 10 tabs rather than 40 and I can view a meangingful amount of each tab's title rather than just the icon. For anybody who isn't aware, and would find this useful, here is the code: tab {min-width: 10em !important;} It at least makes overflow a little less painful. (If I *must* overflow, at least I'd like to do so in a way where the tabs I have displayed mean something.)

I applied the patch, but I don't have a build environment so had to do it via the .jar decompress, patch, recompress method. I also ended up with some patch errors on the last two files, so I'm not sure if what I'm seeing is the result of my own problems or of the patch itself. (Somebody else applying the patch in a proper build environment would be useful here.) So, FWIW: It looks much better. Good improvement. However, some of my criticism from comment 52 still applies. 1. As soon as I hit overflow, I end up with the left-hand scrollbox on top of a partial left-most tab, and a right-hand scrollbox on top of a partial right-most tab. We shouldn't be seeing any partial tabs. If a tab can only be partially shown, then don't show it at all. Every tab shown should be complete. 2. On overflow, the tab bar should remain positioned all the way to the "left" (with tab #1 fully in the left-most positition and everything else disappearing off the right hand of the screen). The left-hand scrollbox should be greyed out (disabled), although still shown, since you can't scroll to the left. As soon as you scroll to the right, the left-hand scrollbox should become active. Once you scroll all the way to the right, the right-hand scrollbox should become greyed out (disabled). 3. When I hover over a scrollbox it activates. I *really* don't think it should do this. Hovering over a scrollbox should, if it does anything, bring up a tooltip. Only when CLICKING on the scrollbar should something happen, and that should be for the tab bar to move a single tab in the direction of the scrollbox clicked. (I click 5 times to move the tab bar 5 tabs in one direction.) 4. This can/should be fixed by addressing my 1st point, but if I've scrolled to the right, so that the left-most tab is only partially displayed, then start deleting tabs until the overflow condition no longer applies (and the scrollboxes are removed) the left-most partial tab is not redrawn to become fully visible again.

> However, some of my criticism from comment 52 still applies. Make that comment 53. <sigh>

Comment on attachment 126909 [details] [diff] [review] Better arrowscrollbox jag, am I wasting my time?

Neil: Don't get me wrong. Your solution is much better than not having one at all. I'd easily be happy to have it checked in and then open another bug to deal with the relatively minor UI problems. (Plus, I don't even know if what I saw yesterday were "real" or not since, as I mentioned, I got patch errors and may have just been looking at a locally corrupted version.) Also, I find it extremely discouraging that I'm the only person here to comment on this. Has nobody else applied the patch and tested it?

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

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

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

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

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

I understand this is an enhancement and gets low priority, but we are in 1.6 now and still haven't gotten a fix for this almost 2-year old thing... Just one comment: I'd like to have the tabs stay in one row, because I've got a widescreen LCD and the screen height is somewhat limited. If the decision is to make them multiple rows, please at least add an option to show single row and use scroll arrows. Thanks.

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

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

(In reply to comment #65) > users who would like to have that, can install TBE. Actually I was aware of that. Yet still I'd really like to have this little bug fixed in the suite, so people don't have to go download and install TBE every time they upgrade the suite. I'm also trying to teach some of my relatives who don't know much about computers to upgrade to Mozilla. They use IE for browsing and Netscape 4.8 for email. I'd hope after the upgrade they can be relatively virus free when browsing websites, and get to use a better email client. To let them go here and there to install extensions is not going to be very intuitive.

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

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

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

Ah, the keyboard-based workaround: control-tab to move to the tab to the right, and shift-control-tab to move to the left. Thanks - that makes my life much easier. It would be nice, once you've opened up your first off-window tab, to see an alert dialog explaining that the tab UI will never be fixed because the developers alrady know the keyboard shortcut the alert tells you about.

Lloyd Wood: (In reply to comment #71) > It would be nice, once you've opened up your first off-window tab, to see an > alert dialog explaining that the tab UI will never be fixed because the > developers alrady know the keyboard shortcut the alert tells you about. Please read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html and keep yourself from adding such comments in the future. And then please tell me where anybody said this will never be fixed. Or did you only imply this because I politely answered your question, trying to help you? Do you consider me a developer? I see: developers are the ones who do not want to fix bu xy and users are the ones who want it fixed. What about: "Lloyd, please fix this bug or I'll tell everybody you do not want this fixed."? Please get a rough idea of open source before posting comments. Just as a hint: if/when somebody decides to fix this, he will do it for free in his spare time. And surely not because you told him to do so. Don't get me wrong: this bug also annoys me sometimes (although I rarely have so many tabs open). But I know that I can't force anybody to fix it.

In the continued absence of a real fix after two years, it would be nice, once you've opened up your first off-window tab, to see an alert dialog explaining the available keyboard shortcuts for accessing off-window tabs. It's a lousy partial workaround, but better than nothing. (vote for this bug to be fixed.)

In addition to what comment #55 mentions, Neil's latest patch has more problems, e.g. with resizing: Open _many_ tabs in a narrow window, scroll all the way to the right and then make the window wider: the new space will not be used for tabs. Or with closing tabs: Create many tabs, scroll to the right, context menu on leftmost, partially visible tab, "Close all other tabs": you will only see that partial tab. (I think I also got it to displaying no tab at all with more usual steps, but can't remember how) I'm not sure if a dropdown would be nicer, because scrolling is a bit confusing when you do not know which scrolling position you currently are at... And: displaying parts of tabs (comment #55, 1.) per se does not look like a real problem to me. I think it makes the solution much easier than forcing only full tabs to be visible. And with a vertical line on both sides where the tabs "disappear behind" this could also look logical.

not going to block 1.7 for this issue.

I just did a test build for bug 76831 and afterwards recognized I re-used the tree with Neil's patch for this bug. Lloyd, Vedran, Darrel and all others: You can profit from this and download the test build from http://i08fs1.atis-stud.uni-karlsruhe.de/~s_kunz/mozdev/bug76831.zip (at least for a few days from now). Please send me a short mail when you do so, so I get a rough estimate of the bandwidth used. BTW: this is a Windows build (that other bug is Win only). I refreshed the tree a few hours ago, so the build you get is a few patches post-1.7b. That other bug's patch will not affect you as long as you don't set a certain pref as described in bug 76831. Of course you are free to do so if you are interested in that bug.

FWIW: I'm now using clav's excellent Flowing Tabs extension (http://forums.mozillazine.org/viewtopic.php?p=546615#546615). There are some issues with how things are presented - mostly because of seemingly silly backend code which I don't understand and which can't be overrridden by the extension via CSS - but it's essentially a quite workable solution to this problem. (He has another extension, Scrollable Tabs, but I don't believe it currently works with Seamonkey.) It could be worthwhile for somebody to see what he's done and try to get a proper patch together for the trunk itself. (I'm not competent enough to do that or else I would.)

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

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

This is a very simple solution that has been mentioned in this bug. I think it would be the fastest, simplest fix for this issue (Without the "X" close boxes as mentioned as WONTFIX in bug 108938). I think if we were to allow multiple rows, that would create added complexity for tabbrowser and would probably need to be a whole new XUL element. My only suggestion is to not do it exactly like Gnome does it. Pressing the arrow shouldn't change the selection tab, but simply move the row over one. If your selected tab will move out of sight, then we'll probably need to take into consideration that we'll lose the visual association between the tab and the X (if bug 117077 is fixed). The current tab might need to be anchored on the left when scrolling in this case because changing tabs as they are scrolled will slow things down immensely and be unexpected behavior. Re Comment #8 - Screen resolution and system font size will have to be put into consideration. Comment #17 - That will make it harder to make the visual association between the X and tab, and also the open tab and the tab's frame. Multiple rows for tabbing seems like something that would also be a lot more work and complexity. I do see the merits, but that won't be as fast as a fix as left and right scroll of tabs. Also, left and right scroll of tabs is standard behavior for tab frames.

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

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

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

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

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

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

(In reply to comment #82) > Agree with Jason's comment #77. FWIW: The FlowTabs XPI is a small (4 Kb), > single-purpose extension, which implements tabs flowing onto multiple rows when > needed. (Link: http://extensionroom.mozdev.org/more-info/flowtabs ). From my > perspective, it works well, and seems a good solution to the basic problem > discussed in this bug regarding what to do when there are lots of tabs. Maybe > something based on this or something like it could be included in the tree? I tried to install Flowing Tabs in Firefox today but couldn't ("This extension is not compatible with versions of Firefox later than 0.10" -- or something to that effect). I also tried Scrollable Tabs but I had to remove it as the remedy was worse than the ill (tabs were made variable-width with full text, meaning less tabs were visible; the [x] close tab button became overlaid by the text of the last visible tab, the advertised scrolling buttons were not there, ...). OTOH, keyboard hotkeys are a good help (and, IIUC, they don't need any particular extension to work): Ctrl-Tab "Next tab (round-robin)", Ctrl-Shift-Tab "Previous tab (round-robin)"; Ctrl-W "Close current tab" etc. It would be nice to be able to select an arbitrary invisible tab but I can live without it. FYI, currently I'm using aviary nightlies; my current one is "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050409 Firefox/1.0.3".

> I tried to install Flowing Tabs in Firefox today but couldn't ("This extension > is not compatible with versions of Firefox later than 0.10" -- or something to > that effect). The original author hasn't updated it to allow installation on newer versions of Firefox, but someone else has. Try the link on http://www.extensionsmirror.nl/index.php?showtopic=232 (I.e. Direct link to repackaged XPI: http://www.extensionsmirror.nl/extfirefox/Flowing_Tabs_0.4_rep.xpi ) > And yes, I have had and needed 70+ tabs open, and having ~4-5 rows of > tabs intruding on webpage space is not what I want to see (potentially, as > x->inf., this could fill the whole screen). I would much prefer a scroll/next > row button or mini scroll-bar. I've been in the same situation (lots of tabs, on 4 or 5 or 6 rows, eating into screen real-estate), but for my 2c, I want to see those tabs on different rows, because that way I can see them all at once, and I often want to toggle between 2 or more specific tabs; If they were all on one long scrollable single row, then I'd be wasting time scrolling around left and right, searching for the correct tabs (and as the number of tabs approached infinity, the more annoying this would get). For me, the annoyance of this is exceeds the annoyance from lost screen-space. > If this is not reasonable, please at least include an option in preferences > between a next-row button and vertically displayed rows. That's what NetCaptor does (or at least used to do - I haven't used it in ages) - offers a choice between multiple rows of tabs, and one single line that can pan left or right. I agree supporting both would be a good solution, but it (like most Mozilla things) will ultimately come down to what the person who creates the accepted patch is willing to implement.

(In reply to comment #88) > > I tried to install Flowing Tabs in Firefox today but couldn't ("This extension > > is not compatible with versions of Firefox later than 0.10" -- or something to > > that effect). > > The original author hasn't updated it to allow installation on newer versions of > Firefox, but someone else has. Try the link on > http://www.extensionsmirror.nl/index.php?showtopic=232 > (I.e. Direct link to repackaged XPI: > http://www.extensionsmirror.nl/extfirefox/Flowing_Tabs_0.4_rep.xpi > ) > Thanks for the link. > > And yes, I have had and needed 70+ tabs open, and having ~4-5 rows of > > tabs intruding on webpage space is not what I want to see (potentially, as > > x->inf., this could fill the whole screen). I would much prefer a scroll/next > > row button or mini scroll-bar. > > I've been in the same situation (lots of tabs, on 4 or 5 or 6 rows, eating into > screen real-estate), but for my 2c, I want to see those tabs on different rows, > because that way I can see them all at once, and I often want to toggle between > 2 or more specific tabs; If they were all on one long scrollable single row, > then I'd be wasting time scrolling around left and right, searching for the > correct tabs (and as the number of tabs approached infinity, the more annoying > this would get). For me, the annoyance of this is exceeds the annoyance from > lost screen-space. > > > If this is not reasonable, please at least include an option in preferences > > between a next-row button and vertically displayed rows. > > That's what NetCaptor does (or at least used to do - I haven't used it in ages) > - offers a choice between multiple rows of tabs, and one single line that can > pan left or right. I agree supporting both would be a good solution, but it > (like most Mozilla things) will ultimately come down to what the person who > creates the accepted patch is willing to implement. Would it be possible to implement something similar to the following? (I haven't invented it; the taskbar on my machine works more or less like this): - By default there is one row of tabs. - The bar can be resized by mouse (and/or by about:config) to allow several rows to be visible at the same time. - Its height will not change spontaneously. - When there are too many tabs for all of them to be visible, an additional button [v] at right opens, when clicked, a drop-down list showing at least the "invisible" tabs.

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

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

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

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

Removing myself from this list.

(In reply to comment #92) ... > Otherwise, lets revisit this early next cycle. Just wanted to flag this for 2.0 cycle.

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

(In reply to comment #53) > 1. I don't like how the scrolling takes place on mouseover rather than click. > It makes it difficult to control the "horizontal movement" of the tab bar. It > should be modified so that left and right scrolling only takes place when the > scroll arrow is explicitly clicked on. Improving the scrolling speed made this a non-issue for me. > 2. There are left-most and right-most tab "artifacts" being shown. In other > words, tabs that are only being partially displayed. <snip> I'm in favor of showing partial tabs - it makes it more apparent to users that there are more tabs that aren't currently shown. My patch shows partial tabs. (In reply to comment #55) > tab. We shouldn't be seeing any partial tabs. If a tab can only be partially > shown, then don't show it at all. Every tab shown should be complete. See previous :) > 2. On overflow, the tab bar should remain positioned all the way to the "left" > (with tab #1 fully in the left-most positition and everything else disappearing > off the right hand of the screen). It does, so long as you dont ask it to focus the tab that overflowed. If I open tabs in the background, they can appear offscreen. This is actually a little annoying sometimes since I can't be sure I successufully middle-clicked the link. Personally I'd prefer to get <80px tabs so I can have more visible. > The left-hand scrollbox should be greyed out > (disabled), although still shown, since you can't scroll to the left. It should, but nsIScrollBoxObject doesn't provide any way to actually determine that :( > 3. When I hover over a scrollbox it activates. I *really* don't think it should > do this. Hovering over a scrollbox should, if it does anything, bring up a > tooltip. Only when CLICKING on the scrollbar should something happen,<snip> See above. > 4. This can/should be fixed by addressing my 1st point, but if I've scrolled to > the right, so that the left-most tab is only partially displayed, then start > deleting tabs until the overflow condition no longer applies (and the > scrollboxes are removed) the left-most partial tab is not redrawn to become > fully visible again. Addressed in the patch I just attached.

I'm removing my vote for this bug because as far as I'm concerned, Firefox 1.5 beta with "Tab Mix Plus" extension is an adequate solution. (Allows flowing tabs, scrolling tabs, or neither; min/max tab width and max no. of flowing-tabs rows are user-settable in the Options UI; etc.etc.etc.) YMMV; see https://addons.mozilla.org/extensions/moreinfo.php?id=1122 and http://forums.mozillazine.org/viewtopic.php?t=327222 Not (yet?) available for the Mozilla suite, but maybe if someone politely asks the author, he might either write a Mozilla version, or allow you to do it yourself (Who knows? If you don't ask, you won't get a "yes" answer).

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

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

I've been working on an extension which allows you to choose between all the main ways of dealing with too many tabs, based on all the suggestions in bug 221684, bug 155325, bug 106927 and bug 139272. I thought I'd do a summary of all the options for this bug, and have included my observations after about 6 months of testing all the possibilities. In no particular order: 1. Arrowscrollbox (aka scroll buttons) ===================================== When you have too many bookmarks, scroll up/down buttons appear at the top and bottom of the bookmarks menu. The same component can be used to show left/right arrows on either side of the tabs, when necessary (the patch to bug 103723 makes it neater). Note: this could just be done with 'normal' scroll left/right buttons, but the effect is the same PROS: very little screen space used, easy to implement CONS: anyone with lots of ungrouped bookmarks will attest that it's really annoying having to wait 60 seconds just to scroll down to that bookmark you wanted 2/3 of the way down, and just generally quite a hard scrolling system to use due to the quirky onhover behaviour, fast scrolling making precise selection hard (though scrolling is also too slow to traverse the set of items), no indication of how far you've scrolled, etc... 2. Scroll up/down buttons ========================= Do what the windows taskbar does: A 2-part button on the right hand side of the tab bar allowing to scroll up or down through the "rows of tabs" (only one row is ever visible at a time though). PROS: very little screen space used, easy to implement CONS: many of the same problems as 1, and not very intuitive as the user expects to scroll left/right, not up/down 3. Scrollbar (horizontal) ========================= Apparently this was present and quite popular in TBE. Either way a scrollbar is a very effective tool for scrolling large numbers of things (unsurprisingly!). It could either just scroll the tab bar (and you have to then click on the tab you want etc.), or have it's position directly linked to the tab index. Note: if there's a way of making scrollbars half their normal height that could be nice PROS: Doesn't take up much screen space, easy to implement and easiest to use of the scrolling mechanisms, especially since scrollbars inherently allow scroll one, scroll row, and scroll manually. CONS: The first time they see it users might not be sure what it does, though if it scrolls as they switch tab it'll soon be obvious. 4. Multiple rows ================ The controversial option - many people want this, many hate it. For it to be sensible there should be a mechanism for dealing with when more than, say, 4 rows or 20% of the screen is taken up by this - adjustable by dragging a splitter (like the windows taskbar does). Then have a vertical scrollbar, or perhaps vertical scroll buttons (possibly even a dropdown). Perhaps the best way of doing this would be to only show the inactive rows when the user hovers over the tab bar for a sufficient period (in this case as many rows as can fit on the screen should be shown before scrolling). I also think that while there are multiple rows tab width should remain fixed (except perhaps on the bottom row), as otherwise tabs wouldn't line up, and would kept moving around, as well as it being an absolute pain to implement. Note that if we allow the number of visible rows to be adjusted by dragging a splitter, we could just set the default to 1, hence allowing users to choose whether to use multiple rows or not. PROS: all tabs accessible at once (unless very many are open) CONS: Where did all my screen space go?, hardest to implement well. 4. Tab menu =========== A dropdown menu shows all tabs, to enable instant selection. This could be accessible via an entry in the Go menu, a button somewhere, and/or a keyboard shortcut. Note that this could be used AS WELL AS one of the options above (except perhaps multiple rows). The important question is what to do when the menu is too long for the screen. Either multiple columns (instant access to all tabs), a vertical scrollbar (unusual but fairly effective UI) or an arrowscrollbox (standard but hard to use, see 'CONS' for option 1). I would also suggest that this menu behave like the tab bar, e.g. right-click to get the tab right-click menu. It may also be nice to switch tabs when the user just hovers over menuitems in this menu, however low-spec systems might suffer so that could be a hidden option or extension. Note: many people have proposed having a "tab overflow menu" launched from a chevron button (>>), however any sensible tabs implementation will make sure the currently selected tab is always on screen (except perhaps if the user then scrolls away), so there would need to be a very clear separation between tabs before those visible and tabs after those visible. Even so this would be confusing. The visible tabs probably should be shown differently (e.g. italic) though, and the active one in particular (e.g. bold). Note2: Or to really make a difference (and complement 1, 2, 3 or 4) this could be sorted by last accessed (or created in the case of tabs which have never been accessed). PROS: see full(er) tab titles when finding tabs, instant access to all tabs, yet little to no screen space used, and novices can ignore it. CONS: erm... slightly slow to get to if in the Go menu? Personally ========== IMHO (after implementing and testing all the possibilities), I find that a horizontal scrollbar underneath the tab bar (3) when tabs overflow is the easiest to use, as scrollbars are very flexible, and also show where you are in the collection of tabs; and having a list of all currently open tabs accessible via a (multi-columned) popup on the Go menu (and keyboard shortcut? like Opera uses Ctrl-Tab...) is the perfect complement to this when instant access to a particular tab is needed. I also found using an arrowscrollbox to be the least effective approach (for the reasons explained above) and would not recommend it. Notes ===== If any of the scrolling solutions (1st, 2nd, or 3rd when not all tabs are shown) are used the display should automatically scroll to keep the active tab onscreen (though the user can still scroll away if applicable). In most cases, the new functionality should only be visible once tabs start overflowing. Whatever the solution (except just 4. tab menu) it may make sense to increase the default minimum tab width. I have programmed almost everything above in extension form (though for Firefox), so would happily convert one of the solutions into a patch. Apologies for the long post!

Comment on attachment 199696 [details] [diff] [review] patch (based on previous patches here) There is so much to read in this bug, but looking at the patch I see a few things that seem wrong: * Why change autorepeatbutton-up to be the left-button? Same for autorepeatbutton-down to right. * <arrowscrollbox> should not be hardcoded to scroll 20px in all cases. Note that this widget is used all over the place; inside menupopups etc. It might be easier to re-do a patch for this bug once bug 222274 is fixed. If I could I'd give this review-.

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

(In reply to comment #103) [...] > One more idea, not sure if better but possible for considering, somewhat > similar to scrollbar - "panning". Grab the tab bar (any tab or empty space) and > drag it horizontally, whole tab bar scrolls the way you pan the image by > dragging it in AcroRead. [...] > Cons: Not very intuitive (no hints that it is there whatsoever), with lots and > lots of tabs it will require repeating "grab and drag" multiple times. Also, it would interfere (especially once the tab bar is full) with tab reordering by drag and drop. ----- (In reply to comment #101) ATM (and just FYI) I'm seeing two Firefox extensions which make this bug much less painful: - Tab Mix Plus http://tmp.garyr.net/ or (for the most recent version) http://tmp.garyr.net/alpha/ -- its options include: When tabs don't fit, make it: [ Scrollable with buttons |v] | Scrollable without buttons | | Multi-row | Max number of rows to display: [ 3 ] Tab width (22~1000): [ 30 ] to [ 250 ] - Tabs menu http://endbracket.net/michael/projects/firefox/ adds a "menu" of all tabs: Tab&s between &Tools and &Help on the main menu bar These two might IMHO serve as a "source of inspiration" for anyone wanting to fix the bug. Note: It has long been debated above what is the "best" solution. TM+ shows that the best solution may be to let the user choose between several possibilities; TabMenu shows that solutions need not be exclusive.

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

(In reply to comment #105) [...] > (In reply to comment #104) > > TM+ shows that the best solution may be to let the user choose between several > > possibilities; TabMenu shows that solutions need not be exclusive. > The devs have made it clear that they will only add one possibility and do not > want more preferences (certainly not visible ones). Though I agree that having > a menu of tabs as well a simple fix could be very useful. Well, in that case the fix, whatever it is, is likely to be "not good enough for me" (I don't know about the next guy but I guess I'm not alone), so I'll keep both TabMixPlus and TabMenu -- and also NightlyTesterTools so I can easily bump the extensions' maxVersion in case their authors don't do so in a timely fashion. FWIW to me, you could as well mark this bug WONTFIX and leave the fix to extension makers (who have already fixed it, both more thoroughly and more flexibly -- more "user-friendlily" if that's a word -- than "the devs" seem disposed to). ;-) Have a nice day!

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

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

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

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

(In reply to comment #108) > Whatever is implemented should be able to work properly with the new tab drag > and drop (bug 105885). The Flowing Tabs extension doesn't - you can only drag > and drop to the top row of tabs. Not a big deal, really, but anything built-in > to the browser should fully support this. > IIUC, the drag-drop mechanism implemented by the Tab Mix Plus extension works on all tab rows when the user elects to have overflowing tabs flow to parallel tab rows. I suggest you take a look at it.

Comment on attachment 199696 [details] [diff] [review] patch (based on previous patches here) no, a scrollbox is not the way to go.

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

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

Just an FYI for reference. This works pretty well in Firefox. I don't know about in Seamonkey, but it may lend a clue or two for usefulness: LastTab (https://addons.mozilla.org/firefox/112/)

(In reply to comment #114) Bug 311696 is listed as a duplicate of this one. Bug 311696 >is< for Firefox. It would be really nice if when trying to find a fix for a problem --- or any info for that matter, if there could be less confusion and more consistancy. Personally, I am spending a couple of hours trying to find out why my scroll wheel on my mouse no longer works on the tab bar in Firefox and I think I am getting cranky. (1st it didn't work after the last upgrade install and then I added the Tab Catalog extension, which states itab scrolling is a feature, and it worked for awhile and then stopped again.) There is no 2nd tab bar. I cannot access tabs past 16, I have to close something to get to it or open a new window. I know there used to be a 2nd tab bar when the 1st got full in Firefox and in Foxfire or Opera there was a view open tabs which gave you list. I would just like to be able to get to the rest of the tabs. If anyone can help you can email me at 2liz@cox.net Liz > (In reply to comment #113) > > It seems obvious to me that this is a critical update for many tab users in > > Firefox. > > This bug is about Seamonkey, not Firefox (hence why it says Mozilla Application > Suite at the top). > The Firefox bug is bug 221684, and is being worked on (it is indeed targetted > for Firefox 2 beta1 and is blocking Firefox 2). > > I expect someone will port the Firefox solution to Seamonkey not long after it > is fixed though. > > > This bug has been open for nearly four years and no agreement has > > been reached. > > Unfortunately complaining on a bug only wastes developers time, those who get > sent your comments already know about the bug. > > > Also, how is it that Bug 161466 was able to be resolved without this being > > fixed first? It seems to me that the block list doesn't mean anything to > > the developers at this point. > > Blocking is more of a suggestion than a requirement ;) >

(In reply to comment #116) [...] > There is no 2nd tab bar. I > cannot access tabs past 16, I have to close something to get to it or open a > new window. I know there used to be a 2nd tab bar when the 1st got full in > Firefox and in Foxfire or Opera there was a view open tabs which gave you > list. I would just like to be able to get to the rest of the tabs. If anyone > can help you can email me at 2liz@cox.net > > Liz [...] The 2nd (3rd, etc.) tab bar is a function of some extensions such as Tab Mix Plus. Rather than closing tabs, you can go from tab to tab (including hidden tabs) by means of keyboard shortcuts such as Ctrl-PgUp/Ctrl-PgDn or (but not in kde) Ctrl-Tab/Ctrl-Shft-Tab.

(In reply to comment #104) ... > - Tabs menu http://endbracket.net/michael/projects/firefox/ > adds a "menu" of all tabs: Tab&s between &Tools and &Help on the main menu bar > > These two might IMHO serve as a "source of inspiration" for anyone wanting to > fix the bug. The url is now: http://mikelward.com/software/firefox/tabs-menu It works here as far as adding the "Tabs" menu item, but it doesn't change the fact that tabs are otherwise hidden. For example, I'll middle click a bunch of links for my bugzilla mail, and then middle click the bug link. That tab and icon will change, but not as far as I can tell if it is out of bounds. Thanks, and I hope this helps.

I just upgraded to Firefox 3.0b2 and am encountering the same issue. The problem occurs when I have searched in the page and have more tabs than the window can hold. I'll submit a screenshot so you can see. If I close the find tab at the bottom the right tab scroll button will reappear.

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

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

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050501 SeaMonkey/2.0a1pre (In reply to comment #122) > It appears to only start to happen at a specific width. At 665 window width > (including the blue window sides) the controls on the side are completely gone. > The controls take up 60 pixels in width so at exactly 725 pixels wide the > controls are completely visible. > Here I can shrink the window, and all controls (scrollbars, etc.) are fully visible as long as there is room in the toolbars for shrinking. When the Location bar has shrunk to an icon with no room for text, the scrollbars move out of sight together with the throbber. Then if I collapse the navigation toolbar by clicking its grippy, the scrollbars come back, so the criterion seems to be "the widest unshrinkable toolbar currently displayed". However, disappearance of the scrollbars has nothing to do with very-many-tabs UI. Thanks to userChrome.css, I always see all my tabs, on two or more rows if necessary. Jayden, you may want to file a separate bug for this.

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

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

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

(In reply to comment #128) > "it is definitely not happening anymore in beta 5" > > As stated several times now, this is a Seamonkey specific bug - so Firefox has > no bearing here (except in terms of any possible port). :) > > I'd actually replied to Tony's comment 125 privately to ask what userChrome.css > entry he was using to allow for multiple rows of tabs - as I hadn't heard of > doing that before. It occurred to me after that that the question, and answer, > does have a direct bearing on this bug (at least as a workaround until things > can be resolved natively) - so I'll just ask it here. > > Also, FWIW, the FlowingTabs extension that I mentioned back in comment 77 > doesn't work with Seamonkey pre2.0. > Some software block prevented my replies from reaching you, but my full SeaMonkey 2.0a1pre userChrome.css (including "flowing tabs" rules, but also parts not relevant here and even a few rules that don't work) is now at http://users.skynet.be/antoine.mechelynck/other/userChrome-seamonkey.css

Thanks for the userChrome.css example! I've taken it, identified the relevant pieces, and simplified the entries. Here is the minimum required to get multi-row tab overflow to work (the rest is just appearance tweaks): --- tabs>stack>vbox>hbox>hbox { display: block !important; overflow: visible !important; } tabs>tab { width: 170px; } --- It appears as if the overflow method requires a static width for the tabs. (You can't have them start off big and then get smaller to a minimum size and then overflow.) If you don't specify a width, it gets set to something very small. The only reason I picked "170px" for mine is that's what made my own tabs both readable and allowed as many as possible to fit on the tab bar without whitespace between the right-most tab and the close button - if anybody else wants to use this, they should experiment for themselves.

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

"With "width:auto; min-width:16px; max-width:1000px" the width gets set to about 25px and indeed seems fixed" I believe that both auto and max-width are being ignored. Since the min-width is greater than the default very small width, it's using that. Anyway - back to the actual bug now. :)

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

Note: The CSS fix I gave in comment 133 for pinning the open and close tab buttons to the top no longer works in the latest trunk (2.1a1pre) builds. It does work in the 2.0 branch builds though. Also tweaking the summary here for better search results (it always take me a bit of time to locate).

Fixed in bug 484968.

Comment on attachment 126909 [details] [diff] [review] Better arrowscrollbox obsolete sr?

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