As brought up in Bug 463827, when just one tab is open, the close tab "X" is gone. But the "Close Tab" drop down is still there. Either that should be removed, or the "X" be brought back.

or change the text to "Close Window" in this instance

That would work as well.

If you set: browser.tabs.autoHide=false browser.tabs.closeWindowWithLastTab=false Then you can have a single tab displayed. If you can close this tab (without closing the window) using any of; CTRL-F4 a context menu the main menu then you should also be able to close it with an "X". There is another configuration option browser.tabs.closeButtons, which is documented as follows: 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) Option 1 says "all tabs" and should mean "all tabs". Perhaps we need an "Option 4" which says "all tabs, excpet when there is only one".

Well, trunk now has the close tab button grayed out when only one tab is open. So, I don't know what did it, but WFM

The documentation for Browser.tabs.closeButtons states that when this setting is set to 1 a close button will appear in EVERY tab. The new behavior of hiding the button when only a single tab is present. Hence it does not show a close button in EVERY tab and it is therefore a bug. If this behavior is desirable then a new value of Browser.tabs.closeButtons should be defined.

In reference to comment #4, the 'X' button should not only appear, but it should be usable, not just grayed out.

(In reply to comment #4) The 'X' button should not only appear, but it should be usable, not just grayed out.

Tom, I think you are talking about a separate behavior, the close X, not the close tab text menu.

Well, now there is no [X] button and the "Close Tab" option in the menu is grayed out. Anyway, it is a bug. 3.5b4

We don't want a close X on the tab when only one is open, because it should be impossible to close a tab and leave the browser open with nothing.

The 'Close Tab' in the File menu as well as the CtrlW shortcut key should also be disabled in the state of only one empty tab open. This could be done in the setStripVisibilityTo method in tabbrowser.xml (which actually has a wrong name, seeing the current implementation).

Agreed, reopening, and changing summary. Didn't notice that.

I've actually intentionally used ctrl+w to close the window with a last tab a few times before, so I think it's probably fine to leave that as-is. I think there's another bug for that around here somewhere, anyway.

When CloseWindowWithLastTab = TRUE, the CtrlW to close the window on the last tab is a valid way. However, when CloseWindowWithLastTab = FALSE, the CtrlW should when the last tab is not empty, reset it to about:blank, and when the last tab is empty, do nothing.

We got a lot of feedback via Litmus that people wonder about the current behavior. They don't expect to see the "Close Window" and "Close Tab" items when only one tab is open. Would be nice to get some feedback from UX.

(In reply to comment #10) > We don't want a close X on the tab when only one is open, because it should be > impossible to close a tab and leave the browser open with nothing. If you use the "show my windows and tabs from last time" option, then you definitely want the ability to close the last tab. When I'm done reading something, I don't want it to load that page again when I next open Firefox.

Honestly, this new behaviour is extremely irksome, to the point of being frustratingly head-banging. With the following settings: a) browser.tabs.closeWindowWithLastTab = false b) browser.tabs.closeButtons = 1 c) browser.tabs.autoHide = false , I fully expect to be able to clear the last tab away (replacing the tabs's contents with that of about:blank) by either using ctrl+w or clicking the tab's X. Right now ctrl+w works as expected, but where is the X? It doesn't make sense to allow ctrl+w but to hide the X for esthetic or some warped "logical" sense. And "fixing" this by not allowing me to clear away the last tab and be presented with a clean slate at all would be absolutely ridiculous. Seriously. The simple fact that you people are entertaining the idea of making it physically impossible to empty the contents of the last tab is insane. As in, unusable, product-destroying insane.

To phrase it more positively: With the following settings: a) browser.tabs.closeWindowWithLastTab = false b) browser.tabs.closeButtons = 1 c) browser.tabs.autoHide = false One would expect that when the last tab is NOT empty, that Ctrl+W and the closebutton on the tab can be used to clear that tab. But when the last tab IS empty, there is no closebutton and Ctrl+W has NO effect at all.

@Alfred: why would you make the exception of hiding the ability to "close" the last tab when it is empty? Much better to be 100% consistent: ALWAYS allow the action. It doesn't hurt anything to permit a noop tab close. I just don't see the point of the code ever having to do an if (only_one_tab_open()) { // special circumstance }. Of course, I'd rather see Alfred's suggestion implemented over some of these other possibilities.

Alex, could we please get some UX feedback? Thanks.

[I'm handling Limi's bugmail while he is out] The ability to close the last tab and by doing so close the window is somewhat contested amongst the UX team. Regardless of if that behavior is available or not, the menu and the presence of the or absence of the close button need to be consistent with each other. (If the close button is absent, the menu command should be disabled).

Disabled, not removed.

the menu command should be disabled, but don't we currently remove the actual button?

Changing title to focus bug on the consistency of the menu items as per comment 21. Changing the behavior for ctrl+w in this instance is a separate issue (which I'd personally prefer be WONTFIXed; comment 13). The current state of Minefield for one tab open is: no close button on tab disabled close tab context menu entry enabled close tab file menu entry (equivalent to close window)

(In reply to comment #23) > the menu command should be disabled, but don't we currently remove the actual > button? Yes, to avoid accidental click, and because disabled close buttons would be confusing.

(In reply to comment #24) > Changing title to focus bug on the consistency of the menu items as per comment > 21. Changing the behavior for ctrl+w in this instance is a separate issue > (which I'd personally prefer be WONTFIXed; comment 13). It's actually very closely linked, because the menu item displays the shortcut key.

>Disabled, not removed. ok, so just to be precise, everyone here already agrees: menu item = disabled close button = removed

(In reply to comment #27) > ok, so just to be precise, everyone here already agrees: > > menu item = disabled > close button = removed No, several of the previous comments (mine included) disagree. Please allow users to close the last tab without closing the window. I don't see how this could possibly harm the user experience in any way.

In principle, the menuitem=disabled,closebutton=removed is ok, but for the special case: if only one tab is left and close-window-with-last-tab=false and the tab is NOT empty: then the close-button could be used to make the last tab empty. When the tab is empty, the close button should be hidden/menuitem disabled. In case of close-window-with-last-tab=true, the close button remains active (to close the window with the last tab). And as comment 26 stated the shortcut key is very linked to this behaviour, and should therefor be the same effect: If close-window-with-last-tab=false and last tab is empty, then Ctrl-W should NOT close firefox, as the actual meaning is nowadays to close the tab (it is the shortcut key of "Close Tab").

(In reply to comment #28) > No, several of the previous comments (mine included) disagree. Please allow > users to close the last tab without closing the window. I don't see how this > could possibly harm the user experience in any way. That's really off topic for this bug, and a request which has been WONTFIX'd several times over. re: comment 29 There's a behavioural difference on OSX and Windows, as well. Closing the last tab in OSX should indeed close the window, as the application stays open. Can't really do that on Windows as it quits Firefox, which is a stronger action / can't be undone as easily.

>Can't really do that on Windows as it quits Firefox, which is a stronger action / >can't be undone as easily. That's my cue to plug bug 594161 :)

(In reply to comment #31) > That's my cue to plug bug 594161 :) Heh, that's one way to do it, but IMO the less standard thing is having a tab-close operation actually close an application in Windows. Just a difference in windowing models between the two OSes.

(In reply to comment #32) > (In reply to comment #31) > > That's my cue to plug bug 594161 :) > > Heh, that's one way to do it, but IMO the less standard thing is having a > tab-close operation actually close an application in Windows. Just a difference > in windowing models between the two OSes. Yeah, agreed. So until we can fix this in a different way, is it fair to say that we want the following behavior? Windows: Do not allow closing of the last tab, and there should no longer be a "Close Tab" in the menu except for in the keyboard-activated case, in which case it is grayed out OS X: Allow closing of the last tab to close the window, since the application stays active. Just trying to clarify what the outcome of this bug should be, sorry if I have misread anything.

Oh, and I don't know enough about Linux window managers to know this 100%, but I assume they have a behavior that is similar to Windows (last window closed = quit the application), and therefore should behave the same way as Windows does.

>is it fair to say that we want the following behavior? yeah, that sounds right. The point of this bug is to make the menus consistent with the presence of a close button.

Whatever is done, the behaviour where pressing ctrl+w when there is only one tab open needs to only CLEAR the tab, and NOT CLOSE it. On Windows, tabs are expected to work according to the MDI (Multiple Document Interface) behaviour. The tabs are CHILDREN of the PARENT window, and as such closing a child should never implicitly close the parent. If I only have one tab open, I expect to be able to empty the contents of that tab without it exiting the application. Windows is not Mac OS, where the expected behaviour is for the window to go away because the app continues to run with a menu. I intuitively hold down ctrl+w to close all open tabs and come to a blank starting point. Please don't ruin this current behaviour.

(In reply to comment #36) > If I only have one tab open, I expect to be able to empty the contents of that > tab without it exiting the application. Windows is not Mac OS, where the > expected behaviour is for the window to go away because the app continues to > run with a menu. I see. That makes sense to me — in other words, being able to close the "content" but get a new, blank tab in its place. We're not trying to protect the last tab as being special, but trying to protect you against accidentally quitting the browser. (In the case of app tabs, we *do* protect you against closing those tabs, but that's handled in a separate bug.)

Sorry, I should have mentioned that I don't really care if the default behaviour of firefox is to close window with last tab. So long as the existing browser.tabs.closeWindowWithLastTab option remains so I can change behaviour to blank the tab rather than close it. Really, I would be very sad to see functionality I use on a daily basis disappear.

when a single tab is open we now show a close X. WFM