Open Bug 597564 Opened 14 years ago Updated 3 months ago

Default minimum tab width should be smaller (to prevent tabscroll)

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Platform:
x86
All
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox7 - ---

People

(Reporter: fabricio, Unassigned)

References

Details

(4 keywords) 

The default minimum width for Firefox tabs is currently too big. And since the fix for bug 574654 it is not possible anymore to easily change that size to 1px, or 12px.

Steps to reproduce:

1- On a relatively big screen (1920px) open both Firefox 4 beta and Chrome.
2- Maximize Firefox 4 window and open 20 tabs.
3- Maximize Chomium and open 60 tabs.

Expected behavior:

Both browsers should display all tab handlers.

Actual behavior:

Only Chrome fits everything in one window. Firefox triggers the tabscroll too early.

PS: I know that the user can modify this size using userChrome.css or installing an addon. But this shouldnt be an excuse for us to continue having a bad default value.
I have now tried Opera and Chrome and both have a minimum tab size much smaller than Firefox, ensuring all open tabs can be directly selected. Opera does it best, though, as when the tabs get so small that the icons can't be fully show the icons are scaled down making it possible (although more difficult) to see what tab holds what. Chrome does it worse as it simply removes the icon when it doesn't fit, making all tabs look identical. 

Personally I'd like the minimum tab size to be large enough to include the icon at normal size and allow for scroll if there are too many tabs (as it is now).
As the much touted "App Tabs" feature shows, there is no problem whatsoever with having very small tabs. But I do think there is a huge problem with having tabscroll, where tabs just "disappear", and you need 2-3-4-5+ clicks to get to them. Assuming you've memorized in what direction you need to scroll.
And the "solution" with the 'custom tab width' extension from https://addons.mozilla.org/en-us/firefox/addon/221515/ just shows it again, that extensions for such vital things are always stupid, because as of now it says "Not available for Firefox 4.0b9pre".

I'd really like the behavior of all other browsers which make tabs as small as they need to without scrolling.
this should be marked as [parity-chrome] and [parity-opera] in whiteboard
This bug is due to 
1.  assuming users are fine with this set min tab width that allows 10 tabs on screen at once and scrolling and/or using Tab Panorama for the other 40+ tabs
2.  removal of functionality from set min tab width in about:config

Users expect a much smaller minimum tab width & now have no recourse save for a 3rd party extension to get that expected behavior.

I suggest a smaller min width (icon size) and/or a preferences menu setting to set min and max tab widths.
Marking this as a duplicate.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
A Firefox UI bug can't be the duplicate of a Camino UI bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
This bug needs [parity-chrome] and [parity-opera] in the whiteboard because those browser have always had this feature.
In the same spirit to Comment 8 this also needs to be marked as a *regression*, since it used to work well before Firefox 2, when tabscroll was made the default.
(In reply to comment #7)
> A Firefox UI bug can't be the duplicate of a Camino UI bug.

Oops.  Missed that when attempting to triage, sorry.  Thanks for catching it.
Will this be fixed? I think this is very important. Tab width in FF4 RC is too big.
Too big for what?
Too big when you have many tabs open and you need to scroll the "tab bar".

Also please add these tags to Whiteboard "[parity-Chrome][parity-Safari][parity-Opera]", dunno about IE, because don't have it installed.
And "ux-efficiency" to keywords
(In reply to comment #12)
> Too big for what?

I think that after all the discussion in Bug 574654, at least that kind of rhetorical question could be avoided.
(In reply to comment #12)
> Too big for what?

Really??

Too big for a reasonable amount of tabs opened to fit in anything less than a 60 inch high resolution screen with the browser window maximized. Is that the answer you look for? Or do we need a Test Pilot survey to state the obvious too?
@ Fabricio Campos Zuardi - please add these tags to Whiteboard - "[parity-Chrome][parity-Safari][parity-Opera]"
and "ux-efficiency" to keywords
done
Whiteboard: [parity-Chrome] [parity-Safari] [parity-Opera] ux-efficiency
Keywords: ux-efficiency
Whiteboard: [parity-Chrome] [parity-Safari] [parity-Opera] ux-efficiency → [parity-Chrome] [parity-Safari] [parity-Opera]
(In reply to comment #12)
> Too big for what?

For info, I currently have 18 open tabs, and I consider that to be on the lower end of my usual usage (I'd say it is mostly 15-25 open tabs at any given time on a 1280x1024 screen)
Also minimum tab width (browser.tabs.tabClipWidth) for showing close button should be smaller.
Regarding usability... the tabscroll is actually a severe usability issue for me.

When I open new tabs, I no longer get a big visual indication that the tab actually opened ... so I end up clicking the link another time and end up getting duplicate extra tabs.

Specific details:
Note: I use open tabs at end (instead of next to current tab).
On a large screen, if I am looking at links on the left side of the window (which is the most common location anyways), then I cannot physically see the very small indicator that a tab opened in the far top, right.  With the old no-scroll system, I got a big visual indicator that I could see without moving my eyes: a new tab would appear and the tab sizes might even resize.  This was enough to see without moving my eyes.

BTW, this is still a problem even if this bug gets fixed.  For everyone using scroll and open at end, the visual indicator is still too small and creates a usability issue.  Should I file a separate enhancement request on this UI problem?
Clearly there are at least 2 camps here, some perfer the tabs to shrink indefinitely, some prefer tab scrolling to start at some level. It cannot be that difficult to make everyone happy with a simple setting of "MinTabWidth" easily available, at least via about:config, if not on a the options dialog.

0 = shrink forever, never enable scrolling
>0 = shrink to this size before enabling scrolling

plus a 'ShowTabIcon' setting:

0 = never show icon
1 = shrink icon
2 = always show full icon - in this case the MinTabWidth should be added to the icon width

or something along those lines.

There is no point whatsoever saying "This is what I want/like", clearly there is a range of opinion so the browser should accomodate that, Surely that is the whole point of having 'options' !!!
BernesB@gmail.com, please do not nominate bugs for tracking without an explanation of why you think the release team should be paying attention to the bug. Thanks. 

I can see no reason why this ought to be tracked by the release team so I'm minusing the nomination.
tracking-firefox7: ? → -
Since this bug is getting old, I am thinking in submitting a patch...

Is this the only file that needs to be modified?

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.css#30

I vote for 40px as the new min-width value. Should I proceed?
(In reply to comment #24)
> Since this bug is getting old, I am thinking in submitting a patch...

No one from the Firefox team or the UX team has commented that this is anything other than "as intended" / "by design".  Without a UX sign-off, a patch would not be accepted. I've cc'd two UX team members for their input.
related bug 583890 so that the smaller tab can still contain unique information.

I think Chrome's approach of making tabs smaller and smaller until they are unidentifiable is kind of ridiculous.  I'm pretty happy with a minimum size of 100px.
50px is pretty identifiable… and less ridiculous than having to use the atrocious tab-scroll
@Alex: Is having maybe 5 characters of the title really that much more identifiable than using one of the most important things in UI design: Spatial and color recognition? MacOS e.g. does not use ANY text on their dock to represent running programs. Users are learning the colors and shapes of icons really fast, and i am 100% sure, most will find the "g" icon of google in 40 open tabs faster then "google - " as a text string. Same for the facebook icon, etc.

Even if the user opens new tabs with "unknown" favicons, again spatial recognition is still achieved much better without the current way of scrolling. Just - again - take an iPhone. Even for seldomly used apps, a user often knows, the "calculator" is on the 3rd page in the bottom right. Having all tabs visible at once, the user still will probably know "that tab is quite at the end, at about 80% of all tabs", whereas with the current horizontal scrolling it is impossible to know where in the tab bar you are currently. Couldn't one at least use paginated scrolling to allow easier spatial recognition?

And as the last point for improving "unidentifiablity": Why not popup the popup with the full title on hover immediately instead of waiting nearly a second? So if the user is really lost with all his tabs, he could at least just hover over all items and read the full title quickly.

Please do at least some end user studies as you often do for other things. Tabs are probably the most important user interface of the chrome next to the awesomebar.
We can spot the correct tab with a glance using icons (which is partly why safari is so frustrating), but because users have multiple tabs open to the same domain, keeping some amount of the title around helps to differentiate them.  This isn't a problem with the OS X dock and the iOS home screen because those targets are guaranteed to be unique.

As for the immediate tooltip, we would really rather the user hit the drop down to display all open tabs, since that provides all of the titles simultaneously, and they won't have to hunt through a series of targets like a 90s adventure game :)

my only other concern with smaller tab sizes is that we need enough space to include the close button when the tab becomes active.  Having the active tab increase in size ends up feeling really strange because all of the other targets move, very accordion like.
Have you done research on how many tabs per domain users keep in one window?
Right now I have 34 tabs open and there is only 2 tabs that are in the same domain.

I like the 40 - that gives more than enough room for both the close button and the favicon.
*by same domain I actually mean have the same favicon
I have around 140 tabs open and just checked that I have several tabs sharing the same favicon (up to 4 sharing the same favicon, about 5 or so groups of 4). Firefox is also using 6 windows (besides the downloads window). I have moved the close icon to the rightmost edge of the tab bar so it is always in the same position if I want to close a tab. But to be able to use 140 tabs, I had to revert to Firefox 3.6 as the later Firefox versions use way too much memory if it can even load all my tabs without crashing due to the 2GB process memory limit in Windows.

I have a minimum tab size shrinking down to just viewing the favicon. This is plenty good for me to navigate around with. I don't use the small scroll icons to scroll the tabbar, but use the scroll wheel on the mouse. It would have been nice if a new row openened temporarily that would show all tabs, shrinking as much as needed to show them. This would eliminate much of my scrolling I think.

I close tabs when my projects related with those tabs have ended (in case you wondered).
In reply to Comment 29 ... some thing worth noting:

* I use tabs for research purposes.  I queue up a whole lot of links that I know I want to check each one.  In this case, several things are true:

1. I don't need lots of visual info (like a text label), because I am going through the tabs via keyboard or one-by-one.
2. Using the drop down is not helpful and bad UX for this situation.  (*) It is a problem because it requires extra clicks and I have to scroll the drop-down.  Since the goal is to be able to see all tabs at once, having to click and scroll defeats this purpose  (*) Is incurs a metal cost in terms of UX design.  A person has to mentally change their mindset from using and organizing horizontal tabs to using and organizing a vertical list.  This is inefficient; ideally, a solution would be to make things work without the scroll list and the corresponding mental change it requires, but I don't have any ideas at the moment. :)

3. Another note: I don't require that the current tab change size to show the title.  Actually, it would make sense to keep it small like the rest of them.


Ultimately, I guess the real problem for me can be reduced to:
1. What I mentioned in Comment 20: it makes it hard to tell if the tab opened or not
2. The extra complexity of switching back and forth between scrolling a vertical list and the horizontal tabs (by this, I mean the subtle UX problems is causes).
Depends on: 677302
Dão Gottwald, do you care to explain why this bug should depend on bug #677302 ? AFAIK this bug is about changing the *default* value to be smaller. To all users. Not a preference.
No longer depends on: 677302
Blocks: 703911
If this issue can't be resolved, may I suggest we at least provide this as a config option?  See Bug 703911
(In reply to Kevin Ar18 from comment #35)
> If this issue can't be resolved, may I suggest we at least provide this as a
> config option?  See Bug 703911

I don't see why this issue can't be resolved. It would be just a matter of someone with the ability to actually approve a new default size to be convinced.

As of today, per asa's comment 23 the people with the power to make such a change would be Mozilla paid employees from either the Firefox team or the UX team. I still believe that there are good and reasonable arguments to make a case for a smaller tab default width, and this can be discussed on newsgroups maybe.

The alternative IMHO would not be a config option, but a Firefox fork instead, with patches for fixes not approved, or not important for the people in charge of Mozilla Firefox "official" distro :)
(In reply to Fabricio Campos Zuardi from comment #36)
> (In reply to Kevin Ar18 from comment #35)

> As of today, per asa's comment 23 the people with the power to make such a
> change would be Mozilla paid employees from either the Firefox team or the
> UX team.

I suggested no such thing and your assertion is false.
Sorry, wrong comment number, I was referring to comment 25, this one:

> (In reply to comment #24)
> > Since this bug is getting old, I am thinking in submitting a patch...
> 
> No one from the Firefox team or the UX team has commented that this is
> anything other than "as intended" / "by design".  Without a UX sign-off, a
> patch would not be accepted. I've cc'd two UX team members for their input.


Also, I am adding another UX team member to cc, since we just chatted about this issue today in argentina :)
This is an old bug, but might I ask the developers to reconsider it?

The min tab width is actually one of the main reasons why I used Chromium instead of Firefox for years. I have a habit of keeping many tabs open at the same time. In Chrome, I have no trouble with that as long as the favicon is still being shown on the tab. It's pretty easy to find a tab out of 30 or 40 open tabs if the favicon is memorable. (Once there are so many tabs open that Chrome starts hiding the favicons, it's time to "clean up".)

In Firefox on the other hand I'm quickly overwhelmed with the tabs if I can't see them all at a glance.

Recently I decided to give Firefox another chance and started using nightly. When looking for a solution to this issue, I found three approaches:

- Adjusting `browser.tabs.tabMinWidth`. Removed in Firefox 4.
- Adjusting `min-width` in `userChrome.css`. But it looks like that is gone in nightly? And if it still works, it won't work for long once XUL is deprecated, right?
- Using an extension. Unfortunately the extensions that do this are XUL based and therefore don't work anymore in nightly.

So it looks like there isn't even a workaround for this anymore. Might I ask the developers to reconsider adding an about:config setting for the min tab width? I'd also recommend changing the default to a value that allows for still seeing the favicon, but cuts off the rest.

I'm pretty happy about the improvements in Firefox lately, but I think this would be a deal-breaker for me.
Apparently I was wrong about userChrome.css, it works when used correctly: The file must be placed in a "chrome" directory inside the profile directory, not directly in the profile directory. This rule seems to help:

    .tabbrowser-tab:not([pinned]) {
        max-width: 250px !important;
        min-width: 30px !important;
    }                                              

Also, if I understand it correctly, XUL was deprecated for addons, but userChrome.css should still continue to work. If that's the case, I'll pull back my request for an `about:config` variable :) The option could be made a bit more accessible to non-developers though.
Currently (as Danilo B) mentioned it is only possible to configure this behavior in Firefox using userChrome.css this is quite intransparent and very hard to find. Also I understand Add-Ons like Custom Tab Width will not be possible anymore in the future (as it can not be implemented as a Web Extension). This will leave us with no easy option to configure this - this needs to be remedied.

Personally I think the scrolling tab bar is a usability nightmare, it makes it impossible for me to find tabs I have open.

Chrome on the other hand does not have a scrolling tab bar and instead continues to make tabs smaller until only the favicon is visible (when they get even smaller the favicon gets hidden as well, when the get even smaller they become triangles that overlap each other).

I suggest switching to the behavior of Chrome by default (arbitrarily small tabs) and allow the current behavior as an option. It might be interesting to introduce this option and gather telemetry what users do with it.
This issue together with the lack of process isolation were the last straws that made me switch to Chrome. Now that Firefox finally got processes I could consider going back if this kind of uselessly introduced usability problems were looked at more seriously. My impression 7 years ago was that the Firefox developers think they know so much better what the users want, that they won't even consider that they could sometimes be wrong. This issue is one of those times.
I read today on nightly's twitter that the default value is changing and the preference coming back.

Details in https://bugzilla.mozilla.org/1404465

So maybe this bug can get resolved /merged with that one.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-opera, parity-safari
Whiteboard: [parity-Chrome] [parity-Safari] [parity-Opera]
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 31 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)
Duplicate of this bug: 1875341
You need to log in before you can comment on or make changes to this bug.