Last Comment Bug 348031 - [Mac] Pressing Cmd-W should always close the window when only one tab is visible
: [Mac] Pressing Cmd-W should always close the window when only one tab is visible
Status: VERIFIED FIXED
:
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: 2.0 Branch
: PowerPC Mac OS X
: P2 normal with 9 votes (vote)
: ---
Assigned To: Mike Connor [:mconnor]
:
:
Mentors:
: 352785 371689 396883 417497 421605 (view as bug list)
Depends on: 365324 392870
Blocks: 431362
  Show dependency treegraph
 
Reported: 2006-08-09 07:59 PDT by Eric Shepherd [:sheppy]
Modified: 2012-08-23 08:42 PDT (History)
31 users (show)
mbeltzner: blocking‑firefox3+
mconnor: blocking1.8.1.1-
jaymoz: wanted1.8.1.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (1.53 KB, patch)
2006-10-26 15:04 PDT, Simon Bünzli
asaf: review+
Details | Diff | Splinter Review
fix (1.67 KB, patch)
2006-10-29 16:45 PST, Simon Bünzli
dveditz: approval1.8.1.1+
Details | Diff | Splinter Review
check-out patch for trunk (1.51 KB, patch)
2007-07-11 02:52 PDT, Simon Bünzli
no flags Details | Diff | Splinter Review
work-around extension (1.11 KB, application/x-xpinstall)
2007-09-08 07:52 PDT, Simon Bünzli
no flags Details
updated to trunk (1.52 KB, patch)
2008-02-28 11:13 PST, Mike Connor [:mconnor]
asaf: review+
mbeltzner: approval1.9b4+
Details | Diff | Splinter Review

Description Eric Shepherd [:sheppy] 2006-08-09 07:59:09 PDT
If you have the always show tab bar option enabled and press Command-W to close the only tab, the window should close but does not.  This is a change  from previous versions of Firefox, and differs in behavior from other Mac browsers.
Comment 1 Simon Bünzli 2006-08-09 08:17:40 PDT

*** This bug has been marked as a duplicate of 341067 ***
Comment 2 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-10-26 12:23:52 PDT
I'm resummarizing this to what I believe is the new goal of this bug, based on the comments in bug 341067. Please correct if it's wrong :)
Comment 3 Simon Bünzli 2006-10-26 12:28:21 PDT
Apparently Cmd+W _always_ closes the window on OS X. That would be reason enough to have Firefox behave differently in that case...

OTOH it might be worth investigating first, what other cross-platform MDI applications do in that situation (such as Eclipse, Opera, etc.).
Comment 4 Mike Beltzner [:beltzner, not reading bugmail] 2006-10-26 13:23:58 PDT
(In reply to comment #3)
> OTOH it might be worth investigating first, what other cross-platform MDI
> applications do in that situation (such as Eclipse, Opera, etc.).

Disagree. Neither of these are applications that get a lot of play on OSX.

This bug is correct. On Mac, the appropriate behaviour of closing the last document within an application is to close the window but leave the app running. We changed the behaviour for w32 when the tab-bar is showing to allow someone to smack on ctrl+w without fear of closing down Firefox. That concern doesn't exist on Mac, so we shouldn't have changed it here, too.
Comment 5 Simon Bünzli 2006-10-26 15:04:33 PDT
Created attachment 243712 [details] [diff] [review]
fix

This patch splits the code for removing a tab when several tabs are opened from the code for replacing the last tab with a blank one when the tab bar is always shown, and makes the second bit conditional for all platforms not being OS X.

Furthermore this patch also focuses the address bar in the second case, thus fixing bug 356581 as well.

This fix might be considered for inclusion into Firefox 2.0.0.*.
Comment 6 diefettenjahre 2006-10-27 10:05:38 PDT
Firefox won't close if "Always schow the tab bar" is activated

This Bug is not only on Mac OS. I think the problem is common for all platforms and systems. If "Always show the tab bar" is activated you can't close Firefox 2.0 when you close the last opened tab (i.e. by using CTRL-W or mouse gestures). This behaviour is different from FF 1.5 and makes no sense.

I'm using Firefox 2.0 on Ubuntu 6.10 and Windows XP Home SP2.

So please change the details (os, platform and so on) to "ALL" and it's priority to a higher level.
Comment 7 Jonathan Gardiner 2006-10-27 10:13:13 PDT
(In reply to comment #6)
> This Bug is not only on Mac OS. I think the problem is common for all platforms and systems.

Sorry, as much as I think it should be a seperate preference, this is intended behaviour on other platforms. The bug 341067 is for all platforms.

It is a bug in Mac OS because the bug 236721 which led to this behaviour was never a problem on Mac OS, and the solution was generally contrary to the concepts of the Mac OS UI.
Comment 8 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2006-10-29 16:29:59 PST
Comment on attachment 243712 [details] [diff] [review]
fix

>Index: browser/base/content/browser.js
>===================================================================

>@@ -1847,22 +1847,31 @@ function BrowserCloseTabOrWindow()
> #ifdef XP_MACOSX
>   // If we're not a browser window, just close the window
>   if (window.location.href != getBrowserURL()) {
>     closeWindow(true);
>     return;
>   }
> #endif
> 
>-  if (gBrowser.localName == "tabbrowser" && (gBrowser.tabContainer.childNodes.length > 1 ||
>-      !gPrefService.getBoolPref("browser.tabs.autoHide") && window.toolbar.visible)) {
>+  if (gBrowser.localName == "tabbrowser" && gBrowser.tabContainer.childNodes.length > 1) {
>     // Just close up a tab.
>     gBrowser.removeCurrentTab();
>     return;
>   }
>+#ifndef XP_MACOSX
>+  else if (gBrowser.localName == "tabbrowser" &&

nit: no |else| after return.

r=mano (Happen to remember why do we check gBrowser's localname?).
Comment 9 Simon Bünzli 2006-10-29 16:45:13 PST
Created attachment 244016 [details] [diff] [review]
fix

(In reply to comment #8)
> (Happen to remember why do we check gBrowser's localname?).

No. I've now added a comment to that end...
Comment 10 Simon Bünzli 2006-11-03 11:23:36 PST
Gavin: Could you please check this in (or point out who's got that job now ;-)) so that we can nominate the patch for Firefox 2.0.0.*?
Comment 11 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-11-03 11:27:47 PST
I'll check this in one the tree reopens, sure.
Comment 12 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-11-06 07:21:05 PST
Checked in, sorry for the delay. I filed bug 359682 to remove the localName checks.

mozilla/browser/base/content/browser.js 	1.733
Comment 13 Mike Connor [:mconnor] 2006-11-07 09:37:53 PST
Not a blocker, but will likely take the patch.
Comment 14 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-11-07 09:39:55 PST
If this lands on the branch, I think the XXX comment should be removed (it's not really useful there, and has already been removed on the trunk). That can happen on checkin.
Comment 15 Adam Guthrie 2006-11-11 11:25:33 PST
*** Bug 352785 has been marked as a duplicate of this bug. ***
Comment 16 Daniel Veditz [:dveditz] 2006-11-29 12:02:01 PST
Comment on attachment 244016 [details] [diff] [review]
fix

approved for 1.8 branch, a=dveditz for drivers
Comment 17 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-11-29 12:06:53 PST
mozilla/browser/base/content/browser.js 	1.479.2.211
Comment 18 John Johnston 2006-12-02 06:49:19 PST
I would like to add a nit pick to this. I use Firefox under both Windows and Mac, when I click ctrl-w in windows on the last tab, I can do an unclose tab and restore what I just closed. With this new patch in place under OS X, that functionality doesn't exist if I lose the window. I think that I should still be able to restore my last tab if I hit command w on the last tab and the window closes.
Comment 19 Simon Bünzli 2006-12-06 08:13:50 PST
QA/testing: Steps to reproduce were:
1. Enable the option to always show the tab bar (Options -> Tabs).
2. Close all tabs but one.
3. Hit Ctrl+W/Cmd+W (or click the tab's close button).

Expected behavior:
On OS X, the window containing that tab is closed; on all other platforms, the tab is replaced with a blank one and the address bar gets the focus.

To make sure that nothing regressed: if more than one tab is open, Ctrl+W/Cmd+W should close the current tab; if only one tab is open and the tab bar is _not_ visible, Ctrl+W/Cmd+W should close the current window.

(In reply to comment #18)
You're requesting either Undo Close Window or a combined Undo Close Tab/Window, both of which belong to a different (enhancement) bug.
Comment 20 Daniel Veditz [:dveditz] 2006-12-15 10:31:12 PST
(In reply to comment #18)
> I would like to add a nit pick to this.

Please don't -- it's a sure way to confuse things and most likely your nit gets completely ignored. File a new bug. one bug, one problem, one fix -- anything else is chaos.

Comment 21 Mike Connor [:mconnor] 2006-12-29 10:59:43 PST
This type of change should not have happened without consideration of all outcomes, specifically bug 365324, which burned me within two minutes of moving to a trunk nightly.

I've backed this out on the 2.0.0.x branch until bug 365324 has a resolution, we should not be making UE-impacting changes on the branch without a clear ui-review and MOA.
Comment 22 Jay Patel [:jay] 2007-01-03 15:48:52 PST
Removing fixed1.8.1.1 keyword, since this was backed out.
Comment 23 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-01-04 19:43:01 PST
... but not in time for 1.8.1.1, so re-adding keyword.
Comment 24 Dave Miller [:justdave] (justdave@bugzilla.org) 2007-01-04 21:37:33 PST
Yeah, this is in the released 2.0.0.1.  I was very happy to discover it shortly after upgrading.  Not being able to Command+W a window on a Mac is a huge turn-off.  I'm sure we'll hear people scream if it goes away in 2.0.0.2 (I know I will).  "Make up your mind, people!"
Comment 25 Mike Connor [:mconnor] 2007-01-04 23:44:13 PST
Which is exactly why changes like this should be made only with the utmost consideration and care...
Comment 26 Jay Patel [:jay] 2007-01-05 01:03:45 PST
It is unfortunate that this change caused bug 365324, so let's try to find a fix for both and get them in a future release.

From past comments (beltzner's comment #4 being one of the reasons we decided to take this fix to begin with), it did seem as if enough folks had thought about the correct behavior... they just didn't test it thoroughly.

Mike:  What do you recommend we do?  Can you find someone to put some effort into this, so we don't deal with a new "regression" in 2.0.0.2 when people like Dave notice that this fix is no longer in the release.   
Comment 27 Eric Shepherd [:sheppy] 2007-01-05 07:50:08 PST
I have to say, I think this change was made with plenty of consideration.  It got debated a lot (too much, even, in my own opinion).  The potential data loss thing is an unfortunate and admittedly unexpected side effect.

I personally continue to believe that backing this out for 2.0.0.2 is a mistake.  We need to attack it from the other end, where the real problem is.
Comment 28 Jonathan Gardiner 2007-01-05 10:36:24 PST
I already suggested this in bug 365324, but if a way to restore tabs after a window has been closed won't be implemented -- which I believe it should -- why not just implement a warning dialog with a "never show this again" button?

I mean, chances are that if you pressed cmd-w on the last tab, and you ignore the no undo dialog, you really did want to close that window. Frustrating the user by not closing the window won't allow that user to later restore a tab from that window after he actually closes it.
Comment 29 Simon Bünzli 2007-01-08 23:18:43 PST
Comment on attachment 244016 [details] [diff] [review]
fix

Mike, Mike: What's the official stance on this? Are we valuing xp parity higher than pp on this issue? (If so, could I please get r/sr on bug 365394 which regressed because of this back-out?)
Comment 30 Simon Bünzli 2007-01-08 23:36:58 PST
(In reply to comment #27)
> We need to attack it from the other end, where the real problem is.

Indeed, and the real problem isn't that there's this one case where people could accidentally lose a tab but that there are still plenty of ways to accidentally lose tabs: e.g. by hitting Cmd+Q when you've got only one tab left -- even in several windows -- or by hitting Cmd+W if you're not that big a fan of the tab bar.

(In reply to comment #21)
> specifically bug 365324, which burned me within two minutes

The question is: are cross-platform users large enough a group to adjust this little known behavior for them (especially since per default the tab bar isn't always visible)? Or is this just /you/ not feeling comfortable with having to use an extension to make Firefox behave as you'd expect. ;-)
Comment 31 Mike Beltzner [:beltzner, not reading bugmail] 2007-01-17 20:34:41 PST
Comment on attachment 244016 [details] [diff] [review]
fix

(Clearing request since this patch already has approval1.8.1.1+ and seems to have landed.)
Comment 32 Jay Patel [:jay] 2007-01-17 22:17:14 PST
mconnor:  Since you backed this out without discussing this with the developer or drivers, can you please take a look at this bug and all other related bugs.... talk with beltzner... and decide what you two want to do here?  
Comment 33 Mike Beltzner [:beltzner, not reading bugmail] 2007-01-17 22:25:55 PST
(In reply to comment #29)
> (From update of attachment 244016 [details] [diff] [review])
> Mike, Mike: What's the official stance on this? Are we valuing xp parity higher
> than pp on this issue? (If so, could I please get r/sr on bug 365394 which
> regressed because of this back-out?)

NOTE: the following comment applies to the 1.8.x branch ONLY

I think we are putting XP over PP in this case, yes. There's a couple of things here:

1. This wasn't a clear regression, and probably shouldn't have gone into 2.0.0.1 without more discussion

2. It's unclear to me that it's a PP issue, since in the default configuration, we behave as per OS expectations. The expectation when the user is in a special mode in which the tabstrip is always present is potentially different. On w32 and linux we decided that entering this mode indicates that users care deeply about tabbed content, and that they might often hold down accel-w as a way of clearing out their set of tabs

3. Whether or not we think the assumption above is apropos is not at issue here; what's at issue is whether or not we think that assumption trumps PP

4 In w32's case, at least, accel-w normally *does* close the application, so we've already decided to trump PP there, which implies that we've already asserted that the "always show tab strip" modality is a special enough case for us to ignore platform expectations and try to do something more useful.

So for 1.8.1.2, I think mconnor's right. All deference to Sheppy and justdave, but we should back out the change from 1.8.1.1 and mark this as REOPENED.

If we feel that this is an issue that needs to be resolved for 1.9/3.0, this is still the bug to do it. We should re-target it as such and re-open debate. I think there's also sufficient argument to make the debate not Mac-only, since Accel-W closes the application in most w32 apps as well (Office being a notable exception).
Comment 34 Simon Bünzli 2007-01-17 22:36:21 PST
(In reply to comment #33)
> So for 1.8.1.2, I think mconnor's right. All deference to Sheppy and justdave,
> but we should back out the change from 1.8.1.1 and mark this as REOPENED.

If so, could I please get ui-r on the patch to bug Bug 365394 asap?

> since Accel-W closes the application in most w32 apps as well (Office being a notable exception).

This is plain wrong. Almost all MDI apps don't close the app itself on Ctrl+W (OOo being the inconsistent exception), most other apps don't bother with Ctrl+W at all (Windows/Internet Explorer being the notable exception).
Comment 35 Eric Shepherd [:sheppy] 2007-01-18 07:02:45 PST
Well, I think I'm going to keep using 2.0.0.1 until this bug is fixed again then, because this issue actually means that much to me. :)
Comment 36 Dave Miller [:justdave] (justdave@bugzilla.org) 2007-01-19 15:27:27 PST
(In reply to comment #35)
> Well, I think I'm going to keep using 2.0.0.1 until this bug is fixed again
> then, because this issue actually means that much to me. :)

I think you'll find a lot of Mac users doing the same, despite the security implications of not upgrading.  Mac users are darn finicky about this kind of stuff.
Comment 37 Jay Patel [:jay] 2007-01-23 15:29:04 PST
mconnor said we aren't going to take this particular fix on the branches, so clearing the blocking flag and adding wanted.  Hopefully folks can come to some sort of agreement on the right thing to do for a future release.
Comment 38 zankou 2007-02-25 12:28:59 PST
shouldn't this be reopened?  i was quite disheartened to find this fix removed from 2.0.0.2.  make up your minds folks.
Comment 39 Eric Shepherd [:sheppy] 2007-02-25 15:58:06 PST
I've disabled autoupdates on all my Firefox installs until this gets fixed.
Comment 40 Chris Bitmead 2007-02-26 14:32:34 PST
I disagree that the window should close if there is only one tab. Rather it should close if there is only one tab AND THAT TAB IS BLANK. This is how it used to work on Mac at least, and the benefit is that you can consistently close tabs/web sites, EVEN THE LAST ONE, whilst still retaining the behaviour of closing the window with one more keystroke. One press clears the final tab. The next press kills the window. Naturally, this caveat would only apply if you use the option to "always show tab bar". Anyway, since 2.0.0.2 was foisted on us, this bug will drive the Mac folks crazy.

Comment 41 Chris Bitmead 2007-02-26 14:39:13 PST
Oh and also, is this bug really closed, given that the bug has only just in the last few days been foisted on the public? Can someone please re-open it unless it really is fixed in some unreleased branch?
Comment 42 Mike Connor [:mconnor] 2007-03-01 12:44:40 PST
*** Bug 371689 has been marked as a duplicate of this bug. ***
Comment 43 Simon Bünzli 2007-03-01 16:17:43 PST
So, back to square one...
Comment 44 Not interested in Mozilla any more 2007-03-24 08:11:31 PDT
This was fixed in 2.0.0.1 and now it's broken again in 2.0.0.2 and 2.0.0.3. This is most annoying, it's a pain to keep having to grab the mouse to close the window. We don't all sit browsing the web all day to having a big white window open all the time is just a pain. Please re-fix this problem.
Comment 45 John Johnston 2007-03-24 08:36:36 PDT
In response to comment 44, add the shift key to your cmd-w key combination and you don't have to reach for your mouse to close the window.
Comment 46 Not interested in Mozilla any more 2007-03-24 08:39:33 PDT
In reply to #45, usefull to know for a temporary work around but this still needs fixing properly. If it stays the way it is I will be stopping our department using Firefox. Stupid things like this make a massive difference to users and should be fixed.
Comment 47 Alistair McMillan 2007-04-02 16:58:01 PDT
Just to add another voice to the chorus.  I'm another user who was happy to see the bug fixed in 2.0.0.1 and disappointed to see it broken again.  On the Mac OS X platform you expect CMD-W to close the window.

For what it is worth I usually use Windows during the day and a Mac at night, and I still find it jarring that this doesn't work.

I would back Chris Mitmead's suggestion.  One CMD-W to close the last tab and another CMD-W to close the window.  Sounds like a good compromise to me.
Comment 48 Jason Weathered 2007-04-02 18:53:04 PDT
Cmd-W definitely needs to close the window if a single blank tab is open. I was somewhat annoyed when this appeared in 2.0.0.2 after having to put up with it on Windows.

Should Cmd-W close the window if a single non-blank tab is open though? I think it should close the tab and leave a blank tab.
Comment 49 Sami Samhuri 2007-04-25 13:23:57 PDT
I use the Tab Mix extension so I get the correct behaviour with Cmd-W, but clicking the X button on the tab itself erroneously keeps the blank window around.

For the correct behaviour on the OS X platform we only have to look to Safari. The close X on the tab is hidden with 1 tab open and the tab bar always visible. Cmd-W in that situation closes the window.

Does there really need to be a discussion on this? I've only used a Mac for 18 months or so and to me it's clear what the correct behaviour is. (Even before opening up Safari to make sure I was right.)
Comment 50 Not interested in Mozilla any more 2007-04-26 08:53:05 PDT
This is getting more annoying by the day, given that JavaScript can open a new window when I click a link, rather than a new tab as I've asked it to do (see bug 324322). Now simply clicking a link means I have a second window that command-w will not close.

Command-w closes the frontmost window, it's always has done since the inception of the Mac some 20+ years ago. I can see if you have two tabs open that closing the front most tab instead is acceptable (if you think of a tab as a kind of window), however if there is only one tab and I ask for a window close it should close.

Comment 49 is correct it's not a discussion, it either gets fixed or poeple will stop using the software. Mac users should not be short changed because Windows cannot cope with having an application running with no open windows.
Comment 51 Simon Bünzli 2007-07-11 02:52:10 PDT
Created attachment 271813 [details] [diff] [review]
check-out patch for trunk
Comment 52 Simon Bünzli 2007-09-08 07:52:50 PDT
Created attachment 280171 [details]
work-around extension

Installing this extension should give you the expected behavior on OS X until this bug gets a proper fix (which BTW anybody around here is free to write, have ui- and code-reviewed and finally checked in in the Firefox 3 timeframe - starting with one of the attachments above, this shouldn't be too difficult for anybody having had the time to write an advocacy comment).
Comment 53 Eric A. Meyer 2007-09-08 12:09:09 PDT
Thank you, Simon!

I'd like to (and did) add my vote to having this fixed for OS X.  As others have pointed out, Safari provides a great example of how Mac users expect a browser to behave as far as tab-closing, and it's telling that Mac users new and old have chimed in to say that the browser is not acting as they expect.

Before installing the extension Simon wrote, I'd literally abandoned Firefox for everyday browsing and only launched it when doing web development.  Now I may move back.  Yes, this behavior mattered that much to me, and it's pretty clear that I'm not the only one who feels the same way.
Comment 54 Alex Faaborg [:faaborg] (Firefox UX) 2007-09-18 18:25:56 PDT
We really need to get this fixed.
Comment 55 Brian Polidoro 2007-09-20 09:04:54 PDT
*** Bug 396883 has been marked as a duplicate of this bug. ***
Comment 56 Mike Beltzner [:beltzner, not reading bugmail] 2008-01-09 19:31:44 PST
Since people have asked about what this means on trunk, I'm going to re-iterate my statements from comment #33:

My opinion is that Cmd+W should always behave in a platform-parity way, but we should not be changing the behaviour of of a function in a minor release.

For 1.8.x branches ...
 - in the default configuration, Cmd+W will close the window
 - when "Always show tab bar" is selected, Cmd+W will not close the window
 - at this point (Firefox 2.0.0.11 is current version as of this writing), I don't think we should change that behaviour as it can cause dataloss and there's no really good way to let all the users know that we're revving the behaviour

For 1.9 ...
 - we should take this patch so that Cmd+W on the last tab always closes the window
 - we should figure out how to deal with the dataloss another way
Comment 57 Alex Faaborg [:faaborg] (Firefox UX) 2008-01-10 07:32:21 PST
> - we should figure out how to deal with the dataloss another way

In terms of UI:
The history menu shows a comprehensive list of recent history regardless of which Firefox window has the focus.  Wouldn't it therefor make sense to have a comprehensive list of all recently closed tabs across all windows in "History > Recently Closed Tabs"

I also really like Safari's approach of "History > Reopen Last Closed Window"
Comment 58 Mike Beltzner [:beltzner, not reading bugmail] 2008-01-29 09:06:38 PST
(In reply to comment #57)
 > I also really like Safari's approach of "History > Reopen Last Closed Window"

Yeah, I'm OK with that. I thought I saw a bug on it, but can't seem to find it now. Anyone know if it's already been filed?
Comment 59 José Jeria 2008-02-12 10:10:42 PST
(In reply to comment #58)
> I thought I saw a bug on it, but can't seem to find it
> now. Anyone know if it's already been filed?
> 

Didn't find any bug, so I filed bug 417029.
Comment 60 Simon Bünzli 2008-02-14 08:50:41 PST
*** Bug 417497 has been marked as a duplicate of this bug. ***
Comment 61 Mike Connor [:mconnor] 2008-02-22 13:52:35 PST
-> taking
Comment 62 Mike Connor [:mconnor] 2008-02-28 11:13:21 PST
Created attachment 306335 [details] [diff] [review]
updated to trunk
Comment 63 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2008-02-28 11:27:24 PST
Comment on attachment 306335 [details] [diff] [review]
updated to trunk

r=mano
Comment 64 Mike Beltzner [:beltzner, not reading bugmail] 2008-02-28 21:54:38 PST
Comment on attachment 306335 [details] [diff] [review]
updated to trunk

a1.9b4=beltzner
Comment 65 Mike Connor [:mconnor] 2008-02-28 22:06:24 PST
checked.in.
Comment 66 Jesse Ruderman 2008-03-07 17:14:52 PST
*** Bug 421605 has been marked as a duplicate of this bug. ***
Comment 67 Tony Chung [:tchung] 2008-03-24 23:59:04 PDT
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008032304 Minefield/3.0b5pre.   Note, Cmd-W does close the window with one tab open, but Firefox remains in an minimized state, and not like a File->Quit.
Comment 68 Steven Michaud [:smichaud] (Retired) 2008-07-08 08:03:40 PDT
For what it's worth, there've been a bunch of people reporting this
change as a bug.  These reports have been duped to bug 431362.

Note You need to log in before you can comment on or make changes to this bug.