348031 - [Mac] Pressing Cmd-W should always close the window when only one tab is visible

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[Eric Shepherd [:sheppy]]

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]

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

Comment 2

[:Gavin Sharp [email: [e-mail]]]

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]

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

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

Attachment: 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]

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]

(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

[Asaf Romano (gone)]

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]

Attachment: 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]

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: [e-mail]]]

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

Comment 12

[:Gavin Sharp [email: [e-mail]]]

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

Not a blocker, but will likely take the patch.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

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]

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

Comment 16

[Daniel Veditz [:dveditz]]

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

approved for 1.8 branch, a=dveditz for drivers

Comment 17

[:Gavin Sharp [email: [e-mail]]]

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

Comment 18

[John Johnston]

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]

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

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

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

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

Comment 23

[:Gavin Sharp [email: [e-mail]]]

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

Comment 24

[Dave Miller [:justdave]]

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

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

Comment 26

[Jay Patel [:jay]]

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

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]

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]

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]

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

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

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

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

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

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

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

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]

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

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

Comment 40

[Chris Bitmead]

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]

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 43

[Simon Bünzli]

So, back to square one...

Comment 44

[Not interested in Mozilla any more]

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]

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]

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]

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]

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]

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]

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]

Attachment: check-out patch for trunk

Comment 52

[Simon Bünzli]

Attachment: 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]

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

We really need to get this fixed.

Comment 56

[Mike Beltzner [:beltzner, not reading bugmail]]

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

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

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

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

[Mike Connor [:mconnor]]

-> taking

Comment 62

[Mike Connor [:mconnor]]

Attachment: updated to trunk

Comment 63

[Asaf Romano (gone)]

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

r=mano

Comment 64

[Mike Beltzner [:beltzner, not reading bugmail]]

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

a1.9b4=beltzner

Comment 65

[Mike Connor [:mconnor]]

checked.in.

Comment 67

[Tony Chung [:tchung]]

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

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.