The default bug view has changed. See this FAQ.

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

REOPENED
Unassigned

Status

()

Firefox
Tabbed Browser
REOPENED
7 years ago
3 years ago

People

(Reporter: Fabricio Campos Zuardi, Unassigned)

Tracking

({ux-efficiency})

unspecified
x86
All
ux-efficiency
Points:
---

Firefox Tracking Flags

(firefox7-)

Details

(Whiteboard: [parity-Chrome] [parity-Safari] [parity-Opera])

(Reporter)

Description

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

Comment 1

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

Comment 2

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

Comment 3

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

Comment 5

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

Comment 6

6 years ago
Marking this as a duplicate.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 268213
A Firefox UI bug can't be the duplicate of a Camino UI bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 8

6 years ago
This bug needs [parity-chrome] and [parity-opera] in the whiteboard because those browser have always had this feature.

Comment 9

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

Comment 10

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

Comment 11

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

Comment 14

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

Comment 15

6 years ago
(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
(Reporter)

Comment 17

6 years ago
done
Whiteboard: [parity-Chrome] [parity-Safari] [parity-Opera] ux-efficiency

Updated

6 years ago
Keywords: ux-efficiency
Whiteboard: [parity-Chrome] [parity-Safari] [parity-Opera] ux-efficiency → [parity-Chrome] [parity-Safari] [parity-Opera]

Comment 18

6 years ago
(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.
tracking-firefox7: --- → ?

Comment 20

6 years ago
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?

Comment 21

6 years ago
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' !!!
Till this is fixed, use this http://userstyles.org/styles/44810/ff3-disable-tab-overflow

Comment 23

6 years ago
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: ? → -
(Reporter)

Comment 24

6 years ago
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?

Comment 25

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

Comment 27

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

Comment 30

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

Comment 31

6 years ago
*by same domain I actually mean have the same favicon

Comment 32

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

Comment 33

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

Updated

6 years ago
Depends on: 677302
(Reporter)

Comment 34

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

Updated

6 years ago
No longer depends on: 677302

Updated

5 years ago
Blocks: 703911

Comment 35

5 years ago
If this issue can't be resolved, may I suggest we at least provide this as a config option?  See Bug 703911
No longer blocks: 703911
(Reporter)

Comment 36

5 years ago
(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 :)

Comment 37

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

Comment 38

5 years ago
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 :)
You need to log in before you can comment on or make changes to this bug.