User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 In Firefox 3b5, if I have just one tab open, and press Cmd-W, the window closes. Firefox 2 behaviour was to always leave a blank tab when Cmd-W was pressed; Shift-Cmd-W closed the window. Firefox 3 behaviour is closing the window immediately upon pressing Cmd-W with one tab open. This happens regardless of whether that tab is blank or not, so I don't think this has anything to do with #358573. There's no longer any way to close the last tab via keyboard shortcut without closing the window as well. Clicking the close button on the final tab does work as intended, leaving a blank tab. It strikes me this would be a common source of complaint if it were the new standard behaviour, so I wonder if it has to do with my settings. I'm not aware of anything non-standard in my about:config, but would be happy to share. My tab preferences are as follows. New pages should be opened in: ( ) a new window (X) a new tab [X] Warn me when closing multiple tabs [X] Warn me when opening multiple tabs might slow down Firefox [X] Always show the tab bar [ ] When I open a link in a new tab, switch to it immediately Reproducible: Always Steps to Reproduce: 1. Open a window with just one tab. 2. Press Cmd-W. Actual Results: The window closes. Expected Results: The tab should close, leaving a blank tab.

Aaron, in Firefox 3, this is intended behaviour on Mac for users with the "Always show the tab bar" preference. This change was introduced by bug 348031. Intended behaviour => resolving wontfix

Okay, so here's the problem. I've spent the last 18 months growing pretty darned accustomed to Firefox on my Mac. Yes, in other applications Command-W closes the window, so I see the desire for consistency; but those other applications don't have tabs. Firefox does, Command-W closes tabs, and Shift-Command-W closes windows. It's the way they're listed in the File menu, it's the way it's worked for a year and a half, and it made perfect sense. It is perfectly consistent, perfectly predictable behaviour. Now the behaviour has changed, in thoroughly jarring fashion. I understand, from reading the other bug thoroughly, that there was a crowd that disliked this functionality; but there were not one, but two viable alternatives, for those folks. They could simply press Shift-Cmd-W instead of Cmd-W to close the window, as I did; or they could hide the tab bar when only one tab was open, and get the exact functionality they desired. Now, instead, there is a completely unintuitive hack, as far as I'm concerned, where the state of the window determines the functionality of a keyboard shortcut and its associated menu item. Furthermore, the keyboard shortcut's functionality differs from that of the GUI button that's meant to function identically; and we also now have a disconnect in functionality between different operating systems. And so before, we had consistent functionality across platforms; consistent functionality regardless of window state; and the ability to either close the final tab and leave the window open, *or* close the window entirely, depending on what the situation called for. Now we have inconsistent functionality across platforms; inconsistent functionality based on windows state; and no ability to close the final tab and leave the window open. I realize there wasn't much opposition to the new functionality in the other bug, but that's because anybody who is used to it — and has *embraced* it — wasn't there talking about it. And judging by comments like tchung's, there's a fundamental lack of understanding of how OS X works if this new behaviour is considered acceptable. With this change, I lose my keyboard shortcut to close a tab; if I close the final tab and want to re-open it, I can't; if I close the final tab and want to immediately visit a new address, I can't. I have lost basic Firefox functionality. Why couldn't the resolution simply have been to hide the tab bar by default on new installations? That way by default it acts exactly like Safari, which seems to be what those folks want; and if the option to always show the tab bar is selected, then use the Firefox functionality I've long grown used to across multiple platforms, machines and Firefox revisions. Bottom line: I should not need an extension to maintain my workflow, and I shouldn't need to look at how many tabs I've got open to figure out what the behaviour of the Close Tab shortcut will be. Close Tab should close tab.

I absolutely agree with Adam on this -- this change is making me crazy. I close the last tab to get to a blank window probably 50 times a day. If you guys are insistent on the "new" behavior staying, can it at least be optional? Even a hidden pref in about:config would be okay.

It's not new behavior. It's the way it worked in Firefox 1.5 and 2.0. They broke it in one of the Firefox 2.0.0.x security updates (and got a LOT of complaints about it), and it got fixed again in Firefox 3. They shot themselves in the foot (giving people time to get used to it, thus creating the complaints you read above) by waiting so long to fix it, in my opinion.

Given the same situation in FF 2 on the Mac and in FF 2 & 3 on Windows, command/control-w will clear the tab without closing the window. This behavior should be changed back (or there should at least be a hidden option to change the behavior) since the new behavior is inconsistent with the behavior on Windows. I believe it's a bug since command-w is attached to the "close tab" file menu command and shift-command-w is attached to the "close window" file menu command. Close tab means close the tab, not the window, so that is the behavior that should be happening. If this change is meant to make FF consistent with other Mac applications, then command-w should always close the window (not just when there is only one tab open) and shift-command-w should be associated with "close tab" and should never close the window (even if there is only one tab). The new behavior is inconsistent with Control-w behavior in FF 3 on Windows and as others have said it is confusing because the behavior is tied to the state of the window. Modes are bad.

(In reply to comment #8) > This behavior should be changed back (or there should at least be a hidden > option to change the behavior) since the new behavior is inconsistent with the > behavior on Windows. There's a lot of things about Macs that are different from Windows. You might remember that one of the major focus areas in Firefox 3 was making things feel at home on the operating system you ran them on. > If this change is meant to make FF consistent with other Mac applications, > then command-w should always close the window (not just when there is only > one tab open) and shift-command-w should be associated with "close tab" and > should never close the window (even if there is only one tab). The way it works now is consistent with how Safari works, too. It turns out that it's a pretty big turnoff to people switching from Safari if they suddenly can't figure out how to close a window.

> There's a lot of things about Macs that are different from Windows. You might > remember that one of the major focus areas in Firefox 3 was making things feel > at home on the operating system you ran them on. If that's true, Command-W should close the window every time. Just because Apple made Safari doesn't make it the gold standard; its tab handling is silly, too. Modal shortcuts are bad; shortcuts should always do the same thing. > The way it works now is consistent with how Safari works, too. It turns out > that it's a pretty big turnoff to people switching from Safari if they > suddenly can't figure out how to close a window. Even though I think this is a poor argument, it's still an incorrect one too; at issue here is functionality when "Always show the tab bar" is turned on. Safari has no such ability, and hence, comparing functionality there is invalid anyway.

I'm all for making an application function like a native app, but that's not what is being done in this case. Firefox is emulating Safari. That's not the same thing as making the app native. Just because Safari is the default browser, does not mean it always "does the right thing". Safari changes the shortcut key command associations based on the state of the window. If there are no tabs open, command-w is attached to close window and close tab does not have a shortcut. If there are tabs open, command-w is close tab and shift-command-w is close window. That is bad UI design. Shortcuts should not change. I don't care if Safari does it, it's bad design and should not be emulated. Also, Safari's behavior violates the HIG. According to the HIG, command-w should always close the window. I know that the main concern is getting people to switch and if they try out Firefox and it behaves strangely they won't use it. But the current behavior is inconsistent and I think that is worse that being consistent with Safari. The best compromise between maintaining external and internal consistency (and if you are going to violate the HIG anyway) would be to always have command-w be close/clear tab and always have shift-command-w be close window. Yes, it may confuse a Safari user initially, but they will figure it out soon enough. Also, on the Mac and in the HIG, when you close the last main window of a program the program should quit (unless the program continues to do something useful in the background, which I would argue Firefox does not). Safari and Firefox violate that as well. My expectation is that when a Safari user closes the last window with command-w they really expect the application to quit (since that is what most other Mac apps do). Since Firefox does not quit when it's last main window is closed, it should not close that last main window. Why would you want a browser running with no windows open anyway. Yes, faster open time would be one reason, but then don't close it, hide it.