Closed Bug 348031 Opened 18 years ago Closed 17 years ago

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

Categories

(Firefox :: Tabbed Browser, defect, P2)

2.0 Branch
PowerPC
macOS
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sheppy, Assigned: mconnor)

References

Details

Attachments

(2 files, 3 obsolete files)

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.
*** This bug has been marked as a duplicate of 341067 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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 :)
Summary: Pressing Cmd-W to close when only one tab is visible does nothing → [Mac] Pressing Cmd-W should always close the window when only one tab is visible
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.).
(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.
Attached patch fix (obsolete) — Splinter Review
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.*.
Assignee: nobody → zeniko
Status: REOPENED → ASSIGNED
Attachment #243712 - Flags: review?(mano)
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.
(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 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?).
Attachment #243712 - Flags: review?(mano) → review+
Attached patch fix (obsolete) — Splinter Review
(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...
Attachment #243712 - Attachment is obsolete: true
Keywords: regression
Whiteboard: [checkin needed]
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.*?
Flags: blocking1.8.1.1?
I'll check this in one the tree reopens, sure.
Checked in, sorry for the delay. I filed bug 359682 to remove the localName checks. mozilla/browser/base/content/browser.js 1.733
Status: ASSIGNED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Attachment #244016 - Flags: approval1.8.1.1?
Not a blocker, but will likely take the patch.
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1-
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.
*** Bug 352785 has been marked as a duplicate of this bug. ***
Comment on attachment 244016 [details] [diff] [review] fix approved for 1.8 branch, a=dveditz for drivers
Attachment #244016 - Flags: approval1.8.1.1? → approval1.8.1.1+
mozilla/browser/base/content/browser.js 1.479.2.211
Keywords: fixed1.8.1.1
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.
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.
(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.
Flags: wanted1.8.1.x+
Depends on: 365324
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.
Keywords: fixed1.8.1.1
Keywords: fixed1.8.1.1
Removing fixed1.8.1.1 keyword, since this was backed out.
Keywords: fixed1.8.1.1
... but not in time for 1.8.1.1, so re-adding keyword.
Keywords: fixed1.8.1.1
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!"
Which is exactly why changes like this should be made only with the utmost consideration and care...
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.
Flags: blocking1.8.1.2+
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.
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 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?)
Attachment #244016 - Flags: ui-review?(beltzner)
Attachment #244016 - Flags: superreview?(mconnor)
(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. ;-)
Whiteboard: need review mconnor, beltzner
Comment on attachment 244016 [details] [diff] [review] fix (Clearing request since this patch already has approval1.8.1.1+ and seems to have landed.)
Attachment #244016 - Flags: ui-review?(beltzner)
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?
Whiteboard: need review mconnor, beltzner → need review mconnor, beltzner [backed out after 2.0.0.1, NOT fixed1.8.1.2]
(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).
Whiteboard: need review mconnor, beltzner [backed out after 2.0.0.1, NOT fixed1.8.1.2] → need review mconnor, beltzner
Whiteboard: need review mconnor, beltzner → need review mconnor, beltzner [backed out after 2.0.0.1, NOT fixed1.8.1.2]
(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).
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. :)
(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.
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.
Flags: blocking1.8.1.2+ → wanted1.8.1.x+
shouldn't this be reopened? i was quite disheartened to find this fix removed from 2.0.0.2. make up your minds folks.
I've disabled autoupdates on all my Firefox installs until this gets fixed.
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.
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: need review mconnor, beltzner [backed out after 2.0.0.1, NOT fixed1.8.1.2] → [backed out after 2.0.0.1, NOT fixed1.8.1.2]
So, back to square one...
Assignee: zeniko → nobody
Status: REOPENED → NEW
Whiteboard: [backed out after 2.0.0.1, NOT fixed1.8.1.2] → [backout needed (trunk)][backed out after 2.0.0.1, NOT fixed1.8.1.2]
Attachment #244016 - Flags: superreview?(mconnor)
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.
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.
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.
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.
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.
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.)
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.
Attached patch check-out patch for trunk (obsolete) — Splinter Review
Attachment #244016 - Attachment is obsolete: true
Keywords: checkin-needed
Keywords: checkin-needed
Whiteboard: [backout needed (trunk)][backed out after 2.0.0.1, NOT fixed1.8.1.2] → [backout needed (trunk): see bug 356581][backed out after 2.0.0.1, NOT fixed1.8.1.2]
Attachment #271813 - Attachment is obsolete: true
Whiteboard: [backout needed (trunk): see bug 356581][backed out after 2.0.0.1, NOT fixed1.8.1.2] → [backed out after 2.0.0.1, NOT fixed1.8.1.2]
Attached file 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).
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.
We really need to get this fixed.
Depends on: 392870
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+
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
> - 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"
Priority: -- → P2
(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?
(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.
-> taking
Assignee: nobody → mconnor
Whiteboard: [backed out after 2.0.0.1, NOT fixed1.8.1.2]
Attached patch updated to trunkSplinter Review
Attachment #306335 - Flags: review?(mano)
Comment on attachment 306335 [details] [diff] [review] updated to trunk r=mano
Attachment #306335 - Flags: review?(mano) → review+
Attachment #306335 - Flags: approval1.9b4?
Comment on attachment 306335 [details] [diff] [review] updated to trunk a1.9b4=beltzner
Attachment #306335 - Flags: approval1.9b4? → approval1.9b4+
checked.in.
Status: NEW → RESOLVED
Closed: 18 years ago17 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: