what's a good browser.tabs.tabMinWidth / browser.tabs.tabClipWidth default? right now the defaults are 120 px and 115 px (from firefox.js). I think that it might be best to make the defaults smaller so that it takes more tabs before the new "scrolling tab strip" behavior is exposed. I'll also post something to the firefox newsgroup to widen the discussion.

It's easier to understand and to access tabs when the minimum is smaller, indeed occasional tab users need not find out about the scrolling mechanism, so personally I'd recommend a smaller minimum around 60px (shows the favicon, 3/4 letters and the ellipsis). This is generally enough to distinguish the tabs. Incidentally it could help to use a smaller ellipsis character, as it takes up quite a lot of space that could be used to show more of the title.

(In reply to comment #1) > personally I'd recommend a smaller minimum around 60px (shows the favicon, 3/4 > letters and the ellipsis). This is generally enough to distinguish the tabs. 60 is also what I've set up. > Incidentally it could help to use a smaller ellipsis character, as it takes up > quite a lot of space that could be used to show more of the title. Indeed. It's 3 dots now, I think. Should be ….

Let me also repeat what I've noted to the news group: "the default icon is obstructive here [when it comes to shrinking tabs] (what's its use anyway?)."

Tab width is set to Min 99 and Max 102. Using an extension to do this. That means that I can load 10 tabs (they fit exactly and have always the same size) and only when I want to load the 11th the scroll buttons appear.

(In reply to comment #4) > I have a 1024 x 768 screen... I once used a % for the width but then there was a sidebar problem.

On Mac+trunk, 60px is enough to show a favicon, one character, and ellipses. That's not more useful than a favicon alone, so I have min width set to 30px. (Having to scroll to get to some tabs is much worse than not being able to see tab titles, at least for my use cases, so I only want scrolling to happen when it is absolutely necessary.)

beltzner tells me that: "...the setting came from NASA's cognitive modelling on when you might accidentally hit the close tab button, which means it's good for determining when to stop showing closebuttons on all tabs." On the trunk I'm going to try this (once I get a review) 1) leave browser.tabs.tabClipWidth (when we stop showing the close buttons on tabs) at 115 px (note, it was 140 px before I changed it for bug #318168. should I change it back?) 2) change browser.tabs.tabMinWidth to 60 px I think this is something we definitely want to figure out for beta 2.

>> Incidentally it could help to use a smaller ellipsis character, as it takes up >> quite a lot of space that could be used to show more of the title. > >Indeed. It's 3 dots now, I think. Should be …. I believe the ellipsis value for cropped text comes from this code: http://lxr.mozilla.org/mozilla1.8/source/layout/xul/base/src/nsTextBoxFrame.cpp#78 It doesn't look like we can override the ellipsis on a per label basis. I'm also not sure if using a html entity would even work (as it would have to be decoded). Let's spin using a different ellipsis out to another bug (but I have a feeling it will be "wontfix" or "invalid").

> On Mac+trunk, 60px is enough to show a favicon, one character, and ellipses. > That's not more useful than a favicon alone, so I have min width set to 30px. For win+branch, for my display, 60 px is enough to show a favicon, two characters and ellipses.

This is what it looks like, 60px: http://img57.imageshack.us/img57/6716/tabs2xb.png 16 and a half tab :)

more info from beltzner about the NASA study: beltnzer: "they found the point at which point error rates for hitting the closebox inadvertently when trying to select the tab got too high (ie more than 2% of the time)" andrea knight: "So, some early data coming back from cognitive modeling done by Google and NASA's HCI group is showing that the likelihood of accidental close in cases where there are 1-5 tabs is less than 1%. It hits 2% around the time tabs hit 135px. I don't have exact numbers yet, but should shortly." so this gives us guidance as to the browser.tabs.tabClipWidth and explains why it was 140 px originally (see bug #308396.) for browser.tabs.tabMinWidth, I'm still favoring 60 px.

drivers (schrep and preed) gave me last minute approval for this on trunk and branch. checked into both trunk and branch. I'll follow up with beltzner/ben/mconnor/etc, etc during beta 2 about the values (140, 60) and other usability issues.

Comment on attachment 228706 [details] [diff] [review] patch for the trunk Hurrah for reviews after checkins!

Need to fix fallbacks in tabbrowser.xml too...

Comment on attachment 228719 [details] [diff] [review] keep tabbrowser.xml in sync with firefox.js thanks; r=mano.

I've landed the supplimental patch on the trunk, and will wait for the branch to open up for b2 to land it on the branch.

no cookie for me. I checked in the right thing to the trunk, and the right patch is in the bug, but I checked in the wrong thing to the one place it matters: the branch before preed's respin. I did 60,140 instead of 140,60. I've justed reversed them on the trunk, on the off chance we have a respin of b1. otherwise, this is a b2 fix. what a shame...I had my chance (for b1) and blew it.

I meant: "I've just reversed them on the branch, on the off chance we have a respin of b1."

thanks to adam (ispiked) for catching my mistake so quickly.

wrong checkin. [Minefield] browser.tabs.tabClipWidth : 140px browser.tabs.tabMinWidth : 60px [Bon Echo/Beta 1] browser.tabs.tabClipWidth : 60px browser.tabs.tabMinWidth : 140px

schrep has given me approval to fix this and preed will be respinning b1, so this is back to being fixed in 1.8.1 / 20b1 thanks again to ispiked for catching this as early as he did.

Verified in RC3 build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1 browser.tabs.tabClipWidth : 140px browser.tabs.tabMinWidth : 60px

At Seth's request, reopening bug to track what this stuff should do in the B2 timeframe when we get a better overflow solution in place. Also, quotes from email: <pkasting> What do you think about changing the pixel-based "width" values to be based more around some integral number of tabs? For example, "overflow once there are 10 tabs visible" instead of "overflow once tabs are 100 px wide". Maybe this is silly to consider, seeing as it'd touch a lot of prefs, would probably change the behavior on browser resize, etc... <sspitzer> I've been thinking about it, and I think it needs to depend on the UI (take into account the favicon size, and on mac, the tab icon size) and also take into account character width (ems) instead of pixels.

(In reply to comment #25) >For example, "overflow once > there are 10 tabs visible" instead of "overflow once tabs are 100 px wide". > Ten tabs open in a window with a sidebar open are much smaller than with the sidebar closed.

(In reply to comment #25) > there are 10 tabs visible" instead of "overflow once tabs are 100 px wide". > Maybe this is silly to consider, seeing as it'd touch a lot of prefs, would > probably change the behavior on browser resize, etc... That's an interesting idea, but I think the better thing to do is come up with a width that maximizes the tradeoff between tab title usefulness/readability and the ability to maximally use the space available on the tabstrip. Mike Connor and I got together and opened up a couple of browser windows at 1024x768 (in w32) and found that with tabMinWidth at 100px, we could - use tab titles to disambiguate between the open tabs - have 10 tabs on a strip without overflow It was a wrestling match, with me tugging the number lower and he tugging it higher, but I think the resulting value is pretty solid. I would encourage people here to try it out for a bit.

in my "straw man", I've set my min tab width to a large value, that (for my display and font size) is pretty close to leaving me with "13em" of tab title. why 13em? See this: http://lxr.mozilla.org/mozilla1.8/source/browser/themes/winstripe/browser/browser.css#73 http://lxr.mozilla.org/mozilla1.8/source/browser/themes/pinstripe/browser/browser.css#134 toolbarbutton.bookmark-item { ... max-width: 13em; ... } In the screen shot, in the personal bookmarks toolbar, see the bookmark is "Checkins on all branche..." (and the corresponding tab). comments?

oops, I didn't read beltzner's comment #27 where he proposes browser.tabs.tabMinWidth : 100px Based on the nasa study, we have should do a clip width of: browser.tabs.tabClipWidth : 140px I'll attach a patch and seek UI review.

Comment on attachment 230530 [details] [diff] [review] pref to change default min tab width to 100 px, per beltzner Update the fallbacks too, please.

thanks asaf.

Comment on attachment 230543 [details] [diff] [review] pref to change default min tab width to 100 px, per beltzner (v2) r=mano if you also fix http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/tabbrowser.xml#111

this has ui-r=beltzner, r=mano

fixed on the trunk.

Comment on attachment 230555 [details] [diff] [review] pref to change default min tab width to 100 px, per beltzner (v3) a=drivers. Please land on the MOZILLA_1_8_BRANCH.

fixed on the branch. on the branch I also changed this to match the trunk: - <field name="mTabMinWidth">125</field> - <field name="mTabClipWidth">115</field> + <field name="mTabMinWidth">100</field> + <field name="mTabClipWidth">140</field> as noted previously, tab clip width is 140 px, per the nasa usability study.

There have been alot of complaints from people about this. They would prefer to have a lot of small tabs, even if you can't see what tabs contains what. Preferred value for them is something like 20px. This is propably the biggest complaint in Firefox 2.0 for what I have seen. I think this bug should be reopened and new solutions should be considered. The current work around using about:config is not acceptable as people consider it too difficult and they always need to ask, before they would even know such a solution.

There is never going to be a "right" answer for this. There have been a handful of complaints, but there are also people who preferred a higher value (like myself, but I don't think that's as true for people without large displays). This was the smallest tab size that still allows for a usable label, so going smaller is incredibly unlikely.

I hate to add another comment from the peanut gallery in Bugzilla, but I second Reijo's comments that smaller tabs are demonstrably easier to use and induce much less loss-of-context than hidden tabs. It's Fitt's Law vs. out of sight out of mind. I would even go so far as to say there should be a preference that prevents hiding tabs *ever*. I've written up some of my thoughts here: http://justinsomnia.org/2006/10/fixing-firefox-2s-new-tab-bar/ In summary, by hiding tabs, you neuter the ability for the tab bar to stand as a browsing timeline (recently opened tabs on the right, older, more important tabs on the left). Which in my experience is the natural evolution of its use. The assumption that the first 3-4 title characters plus an ellipsis (when every tab displays three characters plus an ellipsis) somehow provides meaningful context seems obviously incorrect to me (in the very least, drop the redundant ellipses). Much more important for providing navigational context is the favicon and the location of the tab in that tab bar timeline. But by hiding the tabs at the ends of the tab bar, that navigational context is missing. As I'm Ctrl+clicking links to open new tabs, not only have I lost feedback on the success of the new tab, but I've also lost the context of that newly opened tab in relation to the other tabs around it. Food for thought.

(In reply to comment #8) > >> Incidentally it could help to use a smaller ellipsis character, as it takes up > >> quite a lot of space that could be used to show more of the title. > > > >Indeed. It's 3 dots now, I think. Should be &#8230;. > > I believe the ellipsis value for cropped text comes from this code: > > http://lxr.mozilla.org/mozilla1.8/source/layout/xul/base/src/nsTextBoxFrame.cpp#78 > > It doesn't look like we can override the ellipsis on a per label basis. > > I'm also not sure if using a html entity would even work (as it would have to > be decoded). > > Let's spin using a different ellipsis out to another bug (but I have a feeling > it will be "wontfix" or "invalid"). I filed bug 390282.