Eric Shepherd [:sheppy] Reporter
	Description • 18 years ago

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.

	Simon Bünzli
	Comment 1 • 18 years ago

*** This bug has been marked as a duplicate of 341067 ***

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 2 • 18 years ago

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 :)

	Simon Bünzli
	Comment 3 • 18 years ago

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

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 4 • 18 years ago

(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.

	Simon Bünzli
	Comment 5 • 18 years ago

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.*.

	diefettenjahre
	Comment 6 • 18 years ago

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.

	Jonathan Gardiner
	Comment 7 • 18 years ago

(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.

	Asaf Romano (gone)
	Comment 8 • 18 years ago

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?).

	Simon Bünzli
	Comment 9 • 18 years ago

(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...

	Simon Bünzli
	Comment 10 • 18 years ago

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.*?

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 11 • 18 years ago

I'll check this in one the tree reopens, sure.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 12 • 18 years ago

Checked in, sorry for the delay. I filed bug 359682 to remove the localName checks.

mozilla/browser/base/content/browser.js 	1.733

	Mike Connor [:mconnor] Assignee
	Comment 13 • 18 years ago

Not a blocker, but will likely take the patch.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 14 • 18 years ago

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.

	Adam Guthrie
	Comment 15 • 18 years ago

*** Bug 352785 has been marked as a duplicate of this bug. ***

	Daniel Veditz [:dveditz]
	Comment 16 • 18 years ago

Comment on attachment 244016 [details] [diff] [review]
fix

approved for 1.8 branch, a=dveditz for drivers

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 17 • 18 years ago

mozilla/browser/base/content/browser.js 	1.479.2.211

	John Johnston
	Comment 18 • 18 years ago

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.

	Simon Bünzli
	Comment 19 • 18 years ago

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.

	Daniel Veditz [:dveditz]
	Comment 20 • 18 years ago

(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.

	Mike Connor [:mconnor] Assignee
	Comment 21 • 18 years ago

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.

	Jay Patel [:jay]
	Comment 22 • 18 years ago

Removing fixed1.8.1.1 keyword, since this was backed out.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 23 • 18 years ago

... but not in time for 1.8.1.1, so re-adding keyword.

	Dave Miller [:justdave]
	Comment 24 • 18 years ago

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!"

	Mike Connor [:mconnor] Assignee
	Comment 25 • 18 years ago

Which is exactly why changes like this should be made only with the utmost consideration and care...

	Jay Patel [:jay]
	Comment 26 • 18 years ago

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.   

	Eric Shepherd [:sheppy] Reporter
	Comment 27 • 18 years ago

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.

	Jonathan Gardiner
	Comment 28 • 18 years ago

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.

	Simon Bünzli
	Comment 29 • 18 years ago

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?)

	Simon Bünzli
	Comment 30 • 18 years ago

(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. ;-)

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 31 • 18 years ago

Comment on attachment 244016 [details] [diff] [review]
fix

(Clearing request since this patch already has approval1.8.1.1+ and seems to have landed.)

	Jay Patel [:jay]
	Comment 32 • 18 years ago

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?  

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 33 • 18 years ago

(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).

	Simon Bünzli
	Comment 34 • 18 years ago

(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).

	Eric Shepherd [:sheppy] Reporter
	Comment 35 • 18 years ago

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. :)

	Dave Miller [:justdave]
	Comment 36 • 18 years ago

(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.

	Jay Patel [:jay]
	Comment 37 • 18 years ago

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.

	zankou
	Comment 38 • 18 years ago

shouldn't this be reopened?  i was quite disheartened to find this fix removed from 2.0.0.2.  make up your minds folks.

	Eric Shepherd [:sheppy] Reporter
	Comment 39 • 18 years ago

I've disabled autoupdates on all my Firefox installs until this gets fixed.

	Chris Bitmead
	Comment 40 • 18 years ago

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.

	Chris Bitmead
	Comment 41 • 18 years ago

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?

	Simon Bünzli
	Comment 43 • 18 years ago

So, back to square one...

	Not interested in Mozilla any more
	Comment 44 • 18 years ago

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.

	John Johnston
	Comment 45 • 18 years ago

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.

	Not interested in Mozilla any more
	Comment 46 • 18 years ago

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.

	Alistair McMillan
	Comment 47 • 18 years ago

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.

	Jason Weathered
	Comment 48 • 18 years ago

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.

	Sami Samhuri
	Comment 49 • 18 years ago

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

	Not interested in Mozilla any more
	Comment 50 • 18 years ago

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.

	Simon Bünzli
	Comment 52 • 17 years ago

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

	Eric A. Meyer
	Comment 53 • 17 years ago

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.

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 54 • 17 years ago

We really need to get this fixed.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 56 • 17 years ago

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

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 57 • 17 years ago

> - 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"

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 58 • 17 years ago

(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?

	José Jeria
	Comment 59 • 17 years ago

(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.

	Mike Connor [:mconnor] Assignee
	Comment 61 • 17 years ago

-> taking

	Asaf Romano (gone)
	Comment 63 • 17 years ago

Comment on attachment 306335 [details] [diff] [review]
updated to trunk

r=mano

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 64 • 17 years ago

Comment on attachment 306335 [details] [diff] [review]
updated to trunk

a1.9b4=beltzner

	Mike Connor [:mconnor] Assignee
	Comment 65 • 17 years ago

checked.in.

	Tony Chung [:tchung]
	Comment 67 • 17 years ago

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.

	Steven Michaud [:smichaud] (Retired)
	Comment 68 • 16 years ago

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.