Why does Firefox remove the "close tab button" when you have more than n tabs open unless you focus on the tab?

Question

The origin of this question is that I've tried to find a way to override the behaviour of Firefox which removes the close tab button of unfocused tabs as the number of tabs rises, with no luck.

My issue is that Firefox removes the button to close a tab when the tab bar amount rises to (in my environment) 14 tabs and above.

This is a behaviour that, as far as I'm concerned, is a violation both to consistency and shortcut accessibility, both listed in Schneiderman's Eight Golden Rules, leading to a compromising of the overall UX of the application.

To strengthen my case I have Chrome as a reference which doesn't have that behaviour.

And in my meaning this is the appropriate way, and that Firefox in their approach are violating a number of usability rules.

I see Mozilla's reasoning behind it, they fear users will get annoyed if they accidentally close a tab that they intend to focus. However, is this enough of a big reason to violate consistency and shortcut pattern?

EDIT: dnbrv informed me that Opera uses the same approach as Firefox. And as I took a look at Internet Explorer I saw that they don't use shortcuts at all for tabs that aren't focused. I guess that works in a consistency aspect but it's terrible for shortcut accessibility. Another reason to add to the heap of why I chose not to use ie.

Answer 1

Chrome does the same thing:

There are two reasons for this:

It makes it hard to click close on accident. This is easiest to note on the Chrome example, if every one of those super teeny tabs had an X, it would be extremely difficult to select a tab without closing it. Prefer safe actions. If you have a safe action and a risky action, the risky action should require more work to get to, that's exactly what browsers are doing here.

It focuses on the tab content, not the interface. I don't care that there's a close button on this tab. I care what the tab is. If you're displaying the interface and not the content, you're doing it wrong. When looking at not-focused tabs, chances are I need to know what it is moreso than I need to know how I can immediately close that tab.

You point to Schiedman's rules but you seem to be forgetting #6: Easy reversal of actions. Shortcuts are still intact, and the internal locus of control is intact, so I don't think the "rules" argument is very valid. No, it's not entirely consistent, but consistency which harms readability and usability is not good consistency.

There's also little violation of the "shortcuts" rule. If you're an advanced browser user, you can use middle click to close any tab instantly, which is much faster than targeting the red X even when it's here.

It's also important to note that every single popular browser, including IE and Dolphin and Mobile Safari do this in some way (so it's it's a convention), some browsers simply never show the X on any tab that's not focused.

Answer 2

Maybe, maybe not, but it is not "bad" because it violates a "rule".

Rules don't always work in all situations. One of the main reasons designers exist is to decide when rules ought to be broken, or what rules are useful in a given scenario.

For instance, there are (at least) two general "rules" (I prefer the terms guidelines or patterns, for the record) at play in this case:

1. Maintain consistency - users learn to predict patterns quickly, and you cause cognitive suffering when you break the pattern.
2. Don't clump controls too close together so it is easy to accidentally hit the wrong one.

When only a few tabs are open, guideline 2 doesn't much matter - there's lots of distance between controls. As you add more tabs and distances shrink, guideline 2 becomes more of a concern.

As a thought experiment, imagine the tabs even more tightly packed - at some point, it would be completely impossible to fit the tab close control and the tab select adjacent to each other, and they would overlap - do you allow this to happen in the name of maintaining consistency? (For that matter, aren't you committing consistency misdemeanors every time you shrink the tab width to fit more tabs?)

The real measure of whether this is a good design choice is the effect on users, and would be evident in user observation.

• Do Firefox users experience fewer accidental closes than Chrome users?
• Are Firefox users slower to close tabs than Chrome users?
• Do users generally prefer having the design prefer closing vs. switching tabs? (And at what threshold of tabs on the screen?)

Answer 3

Having the [x] appear at all times takes away from available screen real estate.

Note that when active, the SOF tab can only show Newest '..., but when I'm on another tab, I get just enough more context to know which "Newest"... (Newest 'wpf' Questions)

Edit (to respond to Golden Rules)

shortcut accessibility

-> Ctrl + w

Also, this helps solve #5 Offer simple error handling. This makes it easier to click/focus without closing it. Firefox could also be assuming that a user who has multiple tabs open has them open for a reason (and the user don't want to close them). Whereas a user who only has 3 tabs open, only needs a small amount of tabs for their current context/task.

Answer 4

Firefox 2.0 introduced a number of refinements to its tabbed browsing UI. Among them was the addition of close buttons on tabs. The browser.tabs.closeButtons preference on about:config controls how they can be displayed on tabs.

Possible values and their effects:

0 - Display a close button on the active tab only

1 - Display close buttons on all tabs (Default)

2 - Don’t display any close buttons

3 - Display a single close button at the end of the tab strip (Firefox 1.x behavior)

Since the close button takes up 16 pixels’ worth of tab width, it can obscure the tab’s text if you have a lot of tabs open and the tab widths become narrow. As a compromise, the close buttons are only shown on background tabs if their width is equal to or greater than browser.tabs.tabClipWidth’s value.

The code to set the minimum tab width was moved to this add-on.