Closed Bug 456405 Opened 16 years ago Closed 15 years ago

Closing last tab closes window instead of blanking it

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: djcater+bugzilla, Unassigned)

References

Details

(Keywords: common-issue+, regression, ue, Whiteboard: [see comment #21 and #22]) 

+++ This bug was initially created as a clone of Bug #455852 +++

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080918020356 Minefield/3.1b1pre

Closing the last tab of a window now closes the window instead of blanking the last tab. This was caused by bug 392870. I know it was intentional, but I'm filing this bug for people who don't like the new behaviour.

This was the original summary of bug 455852 before it was morphed.

Bug 236721 is where this problem was originally fixed.
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?
Some reasons for this bug include bug 456405 comment 4, bug 456405 comment 5, bug 456405 comment 24 and bug 456405 comment 25.

I addition to those comments, I have another couple of reasons to add.

Closing the window gets rid of the recently closed tabs list.

Closing the window gets rid of session cookies and other session data (temporarily accepted certificates for one).

Another workflow situation: after following links in a tab, if I want to get back to the page I started at I can go click on the back button lots (or select the first chronological page in the dropdown, or press backspace lots if that's enabled). Now, to start a new "flow" I would previously close the last tab so that it was blank and start afresh. Now though, I either can't use this workflow (start from a non-fresh tab) or I have to open a new tab and close the old one. This is at minimum 2 clicks extra (3 compared to 1). It's not much, but when it's a common action and you're used to the old way, it is an annoyance. It's more than an annoyance if you forget that this change has happened and the browser disappears and you have to load it up again.
My typical workflow is the same as described above.

Another problem this presents:  this resets session-specific settings, like the setting for user agent in User Agent Switcher.  As a user of nightlies, I'm often forced to change my user agent to that of Firefox 2 or 3 to get a page to work correctly (few sites actually identify Gecko correctly) and accidentally closing the window forces me to have to reset those settings.
I agree that the current behavior is good on Mac OS X. Some cases described in comment #1 and comment #2 are never problems on the platform. But those cases become serious problem on Windows and Linux. I think the default behavior is customized for those platforms.

On Windows and Linux, how about following behavior by default?:

 * When there are two (or more) windows, A (has two tabs) and B (has one tab), after I close the last tab in the B, then B is closed.
 * When there is only one window which has only one tab, after I close the last tab, then it is replaced to a new blank tab.

or,

 * When there are two (or more) windows, A (has two tabs) and B (has one tab), after I close the last tab in the B, then B is closed with no confirmation.
 * When there is only one window which has only one tab, closing the last tab is confirmed like: "you are trying to close the last tab and quit Firefox. OK?"

or,

 * When there are two (or more) windows, A (has two tabs) and B (has one tab), after I close the last tab in the B, then B is closed.
 * When there is only one window which has only one tab, the last tab cannot be closed by simple click on the tab (middle-click or left-click on the closebox (possibly it is hidden)).
(In reply to comment #3)
> I think the default behavior is customized for those platforms.

oops, this is "I think the default behavior should be customized for..."
Depends on: 456425
While I like the idea of closing the window when I close the last tab, I would
prefer the option of choosing that behavior.  I have many times closed the last
tab when I didn't mean to.  If there is some way to fully restore the
window/tab, then my concern here becomes moot.  For instance, if session
restore provides that functionality, then I can live with this "feature".
Depends on: 456382
Depends on: 455990
Depends on: 455852
See bug 456382, which I think will fix this.
The second solution from comment #3 seems to be the best.  Whatever the case, bring back the old behavior.  This completely crippled a workflow that I've been using for years now.
The issue in bug 392870 seems to be that opening a new blank tab when clicking a close button seems counter-intuitive. How about just closing the tab and leaving the window open? Having a window open with no tabs might have some technical issues, so how about this solution?:

When the last tab is closed, open a blank tab as before, but hide it in the tab bar, so that it seems like there is no tab open. Clicking any toolbar controls, menus and bookmarks will still work, since there is a tab open. If some kind of navigation occurs in the tab, then un-hide the tab in the tab bar. This way a user can visually see a tab being closed when clicking the close button, and the old behavior can be kept. Creating a new tab would also close the hidden blank tab.
It seems I just submitted my comment to the wrong bug. So here I go again...

What I think is the best compromise is that, when clicking a close button on the last tab, it is replaced with a blank tab w/o a close button (nor close tab context menu, nor close tab keyboard shortcut, etc.). There are several benefits to this: 

1) there's no room for old-time Firefox users to accidentally close the window
2) we still retain the old Firefox behavior
3) the UI will feel responsive, as the closing tab will be replaced with a blank one
4) users can't invoke tab closing mechanism on a blank tab repeatedly and misunderstand that UI is unresponsive, since we already strip out all tab closing mechanism (and the close button isn't shown).
5) The hidden close tab button on a blank tab will serve as a really good visual cue to let the user know that the last blank tab can't be closed. From there, if they want to go to another URL, they can reuse the tab. But if they want to quit using Firefox, they can close it normally, like any other applications on the system (File -> Exit, the upper-right X button, or what have you).
(In reply to comment #9)
> 5) The hidden close tab button on a blank tab will serve as a really good
> visual cue to let the user know that the last blank tab can't be closed.

One could argue that if the user doesn't want to use the blank tab, closing it does make sense and would be a good indication that Firefox can now be closed.
(In reply to comment #10)
> (In reply to comment #9)
> > 5) The hidden close tab button on a blank tab will serve as a really good
> > visual cue to let the user know that the last blank tab can't be closed.
> 
> One could argue that if the user doesn't want to use the blank tab, closing it
> does make sense and would be a good indication that Firefox can now be closed.

Unless they accidentally (or intentionally, being one of those users who assumes they must double-click everything) double-clicked the button, in which case they would have an unpleasant surprise when the window closes when they don't want it to.
We already ignore double clicks.
(In reply to comment #10)
> One could argue that if the user doesn't want to use the blank tab, closing it
> does make sense and would be a good indication that Firefox can now be closed.

I see your point. But to me, in your case it's not an indication that Firefox "can be" closed -- "already closed" would be a more precise term, as the users will realize it "after" the fact, when Firefox is "already closed". And this is a major issue when you have only one window open (since why would you want multiple windows to clutter your desktop when you can use tabs in the first place?).

In short, I'll still argue that leaving a blank tab serves as a better solution if you want to aim for this "can now be closed" goal.

And with all kinds of users considered (old-time and new), I still think it's the best. New users can learn more about tab browsing as planned, and old users are still happy.
This is a bad behavior, this is the magical "make computer explode" button that your grandmother is always afraid of finding. This is counterintuitive for users of all experience levels. It may make sense in theory, but theory needs to give way to practical application. You're closing an app when a user is ONLY closing a document. I am aware of NO application with similar behavior where closing a document closes the entire application.

Example, in MS Word when you close a document, the app stays open. You can create a new document, open an existing one, or stare at the pretty UI, but the app remains until the user explicitly closes it. Opera does not close the app when closing the last tab. Neither Safari nor IE have the ability to close the last tab.

Basically, in Windows at least, there are well defined methods to closing an app. The "red X" and File>Close/Exit/Quit. Double clicking the app icon in the upper left is a holdover from Windows 3.1, and most users won't discover this since that icon really has no other function used by most people. However, NO application I am aware of has a section of the UI that equates to a hidden Quit function. This behavior is counterintuitive, breaks user expectations, and can be disruptive to the workflow of people who use it as a function to merely clear the sole tab. The tab bar is off by default when there's one tab, so most users will never use this feature anyway. Those who WOULD see this feature would most certainly expect not to find it.

I'm not complaining solely because I discovered it and it's incredibly annoying, I'm arguing against it because I truly do feel this is NOT in the best interest of users. If this MUST stay, I feel VERY strongly that it needs to be off by default. This is just not a beneficial behavior.
I couldn't possibly agree with you more.  Tabs turn Firefox into an MDI application.  I have never encountered an MDI app that exited if there were no documents open.

You put that much more eloquently than I could have.
jX, unless you care about the keybinding case (hidden-pref'd in bug 455852, this bug is essentially about the default setting of that pref), I think you want bug 456382
Excellent point, I meant to cc on both. Comment still mostly stands.
The feature totally breaks the usability. For an application where closing and opening tabs is not an every minute business, it makes sense to close a window when the last tab is opened. But for firefox, especially with "Show my windows and tabs from last time", it doesn't make any sense.

Not to mention the people like me who use "Always show tab bar". Closing window with last tab converts this feature into a gimmick.
Note that the issue is the default value of
browser.tabs.closeWindowWithLastTab
and whether it should be controlled by a TAB option setting.

You can fix this for yourself by opening about:config and setting the above to false.
(In reply to comment #21)
> Note that the issue is the default value of
> browser.tabs.closeWindowWithLastTab
> and whether it should be controlled by a TAB option setting.
> 
> You can fix this for yourself by opening about:config and setting the above to
> false.

...or by adding the line
user_pref("browser.tabs.closeWindowWithLastTab", false);
to <your profile>/user.js (a file which doesn't exist by default), which will enforce that setting at every startup, even if its default changes (possibly more than once) over successive builds of Minefield that you might run.
Ah! I didn't know that.
One thing is missing though: addition of close button on the last tab (at least when browser.tabs.closeWindowWithLastTab is false).
(In reply to comment #23)
> One thing is missing though: addition of close button on the last tab (at least
> when browser.tabs.closeWindowWithLastTab is false).

That is intentional and was bug #455990. I don't like it either, though.
It makes me sad. For people with "always show tabbar", it is a regression which introduces useless inconsistency. Firefox's behavior should be consistent for all the users.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: wanted-firefox3.1?
Flags: wanted-firefox3.1-
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Resolution: --- → WONTFIX
I knew this will be WONTFIXed. But i also know that it'll be reopened few days after the final 3.1 release. :P
You can't even close the last tab any longer, so it is now really an INVALID bug instead of a WONTFIX I guess.
CTRL-W or middle mouse click on the tab closes the tab just fine - which is why this is a problem - ctrl-w or a middle click on the last tab and the browser is GONE.
Closing the window with middle click on the last tab is bug 456382. Can't find one for the ctrl-w issue (which bugs me a lot FWIW).
this is incomprehensible for me (especially because I use Fx in fullscreen and I never know whether that tab is the last tab bf hitting ctrl-w)... At least in previous versions, you could check the "always show tab bar" to disable this "feature" (bug)... now with 3.5, I have to find that weird about:config setting...
Blocks: 501748
Keywords: common-issue?
Reopening this since it appears to be a very common issue and asking for revaluating the WONTFIX of this bug.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I will go back to 3.0.x and leave 3.5 if you didn't fix this bug! I threaten! :P
http://support.mozilla.com/kb/Closing+the+only+tab+closes+the+window?bl=n now documents this so hopefully we'll have fewer people here.
(In reply to comment #21)
> Note that the issue is the default value of
> browser.tabs.closeWindowWithLastTab
> and whether it should be controlled by a TAB option setting.
> 
> You can fix this for yourself by opening about:config and setting the above to
> false.

NO!
No matter if I set the above setting to true or false, the red X simply disappears (yes, it first appears then disappears. lol).

By the way another use of closing the last tab is to unload a page from the memory while keeping Firefox in the memory.
A tab containing e.g. Youtube may use much memory. A tab containing a badly-written flash may use much CPU as well. (Not to mention unstoppable background musics, etc.) Closing tabs like these makes you happy :) . But you may want to continue browsing without closing Firefox.
(In reply to comment #47)
> NO!
> No matter if I set the above setting to true or false, the red X simply
> disappears (yes, it first appears then disappears. lol).
It is bug 455990. It requires more sophisticated solution. You can either use Stylish http://userstyles.org/styles/12101 or directly change userChrome.css http://forums.mozillazine.org/viewtopic.php?p=6134615#p6134615

> By the way another use of closing the last tab is to unload a page from the
> memory while keeping Firefox in the memory.
> A tab containing e.g. Youtube may use much memory. A tab containing a
> badly-written flash may use much CPU as well. (Not to mention unstoppable
> background musics, etc.) Closing tabs like these makes you happy :) . But you
> may want to continue browsing without closing Firefox.
Is it related to this bug or is it just one of these bugs with Flash?

(In reply to comment #26)
> I knew this will be WONTFIXed. But i also know that it'll be reopened few days
> after the final 3.1 release. :P
He was right :-) I believe the right solution would be to add this option to preferences window but as I understand it's impossible to do it in Firefox 3.5.* after it was released.
(In reply to comment #48)
> (In reply to comment #47)
> > NO!
> > No matter if I set the above setting to true or false, the red X simply
> > disappears (yes, it first appears then disappears. lol).
> It is bug 455990. It requires more sophisticated solution. You can either use
> Stylish http://userstyles.org/styles/12101 or directly change userChrome.css
> http://forums.mozillazine.org/viewtopic.php?p=6134615#p6134615
But remove the X button? It worked well in older releases and people got used to it. I saw many forums demanding that button. At least a check box in the preferences window. But the solution would be to show the button by default.


> > By the way another use of closing the last tab is to unload a page from the
> > memory while keeping Firefox in the memory.
> > A tab containing e.g. Youtube may use much memory. A tab containing a
> > badly-written flash may use much CPU as well. (Not to mention unstoppable
> > background musics, etc.) Closing tabs like these makes you happy :) . But you
> > may want to continue browsing without closing Firefox.
> Is it related to this bug or is it just one of these bugs with Flash?
No. It's just a long description of the need to quickly close a tab. Any tab. Even the only tab.
And beginner users may need this as well. And they may don't want to learn about hotkeys, workarounds, google, etc.


> (In reply to comment #26)
> > I knew this will be WONTFIXed. But i also know that it'll be reopened few days
> > after the final 3.1 release. :P
> He was right :-) I believe the right solution would be to add this option to
> preferences window but as I understand it's impossible to do it in Firefox
> 3.5.* after it was released.
Why impossible??? It can be fixed as fast as it was screwed. Just comment out the code that hides the X and exits Firefox. People upgrading from 3.0.x won't even notice anything.
Sorry, its really bug 455990. But ordinary users like me may not see the difference. That can be seen also in the comments above. Simply there's a need to close the last tab.

"People upgrading from 3.0.x won't even notice anything."
Only if upgrading to the version in which it gets fixed of course. (if ever it gets fixed.)
(In reply to comment #9)
> It seems I just submitted my comment to the wrong bug. So here I go again...
> 
> What I think is the best compromise is that, when clicking a close button on
> the last tab, it is replaced with a blank tab w/o a close button (nor close tab
> context menu, nor close tab keyboard shortcut, etc.). There are several
> benefits to this: 
> 
> 1) there's no room for old-time Firefox users to accidentally close the window
> 2) we still retain the old Firefox behavior
> 3) the UI will feel responsive, as the closing tab will be replaced with a
> blank one
> 4) users can't invoke tab closing mechanism on a blank tab repeatedly and
> misunderstand that UI is unresponsive, since we already strip out all tab
> closing mechanism (and the close button isn't shown).
> 5) The hidden close tab button on a blank tab will serve as a really good
> visual cue to let the user know that the last blank tab can't be closed. From
> there, if they want to go to another URL, they can reuse the tab. But if they
> want to quit using Firefox, they can close it normally, like any other
> applications on the system (File -> Exit, the upper-right X button, or what
> have you).

This is the behaviour I would expect.

How about, after the last tab is closed (and a blank tab with no close button is displayed), the content-area of the new blank tab is faded (maybe #ccc)?

This would show that the original tab was closed and discourage people from trying to close the last blank tab?

Or, instead of having the last blank tab faded, it could have a short text with a message, or instructions, or something... kind of like IE7+ has: "Welcome to Tabbed Browsing", "You've opened a new tab", ... but I hope the message would be more insightful or be able to turn if off!
Flags: wanted1.9.1.x?
It's worth noting that the 'Tab Mix Plus' add in has a check box that allows you to leave the window open after the last tab has been closed or forces the last tab you have open to stay open.

Since reporting this bug, I've found this option immensely useful.
We are now unable to close a single tab--in the previous release closing the a single tab reverted to a "clean" or new tab.

To close a single tab you must create a second tab , then you can close the previously single tab.
http://support.mozilla.com/kb/Closing+the+only+tab+closes+the+window?bl=n links to an extension for a workaround so you don't need to get Tab Mix Plus which isn't compatible with 3.5.1
Keywords: common-issue? → common-issue+
I can't understand why users have to do a "technical" (I'll bet 95%+ of users don't know about:config exists) two-part workaround to restore previous functionality.  Does anyone other than the devs like this new behaviour?  Surely the old behaviour is more sensible: when tab bar set to "always visible", last tab should have an X, and that X should blank the tab.  As (all?) others have said above, the current default behaviour seems counter-intuitive and cumbersome.
I don't know why I'm posting this, as I personally dislike the new behaviour immensely, and do NOT want my browser closing when I press Ctrl-F4.  In an MDI application, Ctrl-F4 closes the current document, whilst Alt-F4 closes the application. This has been the case since about 1990.  If you close the last document, you should be left with a blank workspace (my general preference) or else it should be replaced by a blank document (probably better in the context of a web browser).

However, it seems that Firefox is not alone in arbitrarily modifying the standard and long-established UI behaviour in this way, as both Chrome and IE7 close the whole browser if you hit Ctrl-F4 in the only open tab.

In addition, Chrome still shows the 'close tab' button even when there is only one tab.  In IE7 this button is removed when there is only one tab, and the right-click 'close tab' option is greyed out, however 'Close tab' is still on the file menu and using this or any equivalent keyboard shortcut closes the browser.  (I haven't tested, but I assume IE8 behaves the same as IE7 in this regard.)

This kind of thing really annoys me - it's the equivalent of changing 'Undo' to use Ctrl-U instead of Ctrl-Z, 'because it makes more sense'.  It is the kind of reasoning employed by someone who has never used the shortcut, and who clearly doesn't understand why Ctrl-Z was chosen in the first place.  The only people it affects are people who are used to and who depend on the old behaviour.  Anyone who was not already using the old behaviour is unlikely to use the new behaviour either, so there is no advantage in the change.

This issue is the same.  The people who use keyboard shortcuts in Firefox are being penalised, to nobody else's benefit.  Please, please, please make Ctrl-F4, Ctrl-W, etc. work as they are supposed to, and not follow the bad habits and sloppy attention-to-detail of those other browser makers!
With 61 comments on this "bug" it becomes abundantly clear that this "feature" should never have been implemented. Now that I understand its origin and workaround I can deal with it, reluctantly. With Fast Dial installed I never saw a blank window so imagine my shock when Firefox disappeared upon clearing the last tab. I agree it should be a selectable option and not dependent on knowing how to deal with about:config assuming, of course, that the behavior cannot be removed completely. I can see no logical reason for keeping it.
Flags: wanted1.9.1.x?
Ctrl+W is marked in the menu as being assigned to closing a tab -- a reversible, minimally destructive action. In current Firefox, for no discernible reason, using Ctrl+W does the same as Ctrl+Shift+W, ie. closes the window. This is an undesired, and unexpected behavior. There is no reason to expect that closing a tab would exist an application.

Furthermore, the last tab now lacks a [x] button, which has the aesthetic problem of leaving text running of to the edge of the tab, and functional problem of now allowing me to close the tab.

Googling the problem reveals that I need a about:config modification _and_ an addon to restore expected behavior. This seems to be more of a bandage than a solution.
To be honest, I noticed this behavior a long time ago - but since I use an extension called TabMixPlus for a variety of features that it contains, and since it contains the fix for this behavior, I have not accidentally closed my window in a very long time when closing the last tab.

However, I believe it would not be too much of an issue (seeing as there are a lot of users clamoring about this) to simply make it a selectable option in the Options dialog on the Tab menu.  Then, you would have everyone covered on this issue - both users who want it as it now works and users who want the old, familiar 1.x behavior.

Since TMP definitely makes it work correctly (regardless of the user's choice)  why not incorporate the code and make the option directly in Fx and be done with it?
(In reply to comment #62)
> With 61 comments on this "bug" it becomes abundantly clear that this "feature"

Please, let's not make "there are X many comments" or "X many votes" extrapolations. It's not good science, and that besides, 61/300,000,000 = not much of a convincing argument, even if you apply the standard "one comment represents a thousand users" math. (also, 61 is barely scratching the surface of potential user rage, see https://bugzilla.mozilla.org/show_bug.cgi?id=mng)

This is a design decision, and some of those decisions will be unpopular. Sorry. There are add-ons to scratch your particular itch.  As has been pointed out (see comment 61) this is the behaviour that exists across all browsers. I don't think comparisons to MDI UIs are valid, as most MDI UIs have a "shell" in which sub windows are contained. We don't.

> workaround I can deal with it, reluctantly. With Fast Dial installed I never
> saw a blank window so imagine my shock when Firefox disappeared upon clearing

Sounds like the author of Fast Dial should be encouraged to change the default last tab close behaviour!

> the last tab. I agree it should be a selectable option and not dependent on
> knowing how to deal with about:config assuming, of course, that the behavior
> cannot be removed completely. I can see no logical reason for keeping it.

Absolutely not. Less preferences, more customization through third party add-ons, please. You need to understand that most users do not find this disturbing, and indeed don't really run into the problem. I'm sorry that you do, I honestly am. I need to build a browser that's best for most people, not specifically the 61 people who commented on this bug.

Thanks for your patience and understanding.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → INVALID
if firefox 3.7 will have the rigid home-tab on the left this issue would become invalid anyway.
(In reply to comment #71)
> Please, let's not make "there are X many comments" or "X many votes"
> extrapolations. It's not good science, and that besides, 61/300,000,000 = not
> much of a convincing argument, even if you apply the standard "one comment
> represents a thousand users" math. (also, 61 is barely scratching the surface
> of potential user rage, see https://bugzilla.mozilla.org/show_bug.cgi?id=mng)
Why not? You should be happy to have feedback from _real_ users.
99% (or very close) of the 300 million users you've estimated doesn't even know what a browser is nor the name of the browser, they've got it preinstalled or someone else installed it for them.
People who comment on bugzilla are the users who made Firefox popular, you should value them and their oppinion very much.

> This is a design decision, and some of those decisions will be unpopular.
The design should serve the users, not someone's hidden wish to design.
What's the point in a design what is not for the users?

> Sorry. There are add-ons to scratch your particular itch.  As has been pointed
Sorry, I would like to use FF for the reason I've started to use originally: because it's good, not because I have to hunt add-ons.

> out (see comment 61) this is the behaviour that exists across all browsers. I
Another reason people started using FF and made it popular was that it _was_ different to other browsers. If you start copying other browsers why would I continue using FF? If I would want something that behaves like IE or some other browser than I would use IE or some other browser.

> don't think comparisons to MDI UIs are valid, as most MDI UIs have a "shell" in
> which sub windows are contained. We don't.
Such a weak excuse. And who cares about a techincal detail?

> add-ons, please. You need to understand that most users do not find this
> disturbing, and indeed don't really run into the problem. I'm sorry that you
> do, I honestly am. I need to build a browser that's best for most people, not
> specifically the 61 people who commented on this bug.
How do you know what is good for the nameless mass of people who don't know the difference between a browser and a word processor, they don't even know that bugzilla exists. Did you conduct a survey or asked the users some other way?
(In reply to comment #73)

Although I think the end-user-stupidity hyperbole went a little far, the rest of this comment is spot-on.

Users were not consulted about their preferences... not even the nightly testers. As far as I've seen, nobody requested this change... it was simply a "design decision."  "Design" for design's sake is bad.

A program is responsible for its own configuration.  Extensions are supposed to extend functionality, hence their name, not add checkboxes for builtin options.  I don't go firing up my "Photoshop Configurator" app just to change my swapfile location.  I certainly don't add a plugin to MSWord so that I can change my print settings.

(In reply to comment #71)
>mng
You're pointing out a bug that's been open for *ten years*.  Hardly a comparison.

> You need to understand that most users do not find this disturbing, and indeed don't really run into the problem.

Did you poll them to be able to state that?  This also implies that most users never even saw the old behavior, so clearly not enough of them could be found that disliked the old behavior so much that it required changing for everyone.  There wasn't even an about:config option added until enough users raised hell about it.

> Thanks for your patience and understanding.

... what patience and understanding?  Sorry, but we really have none, at this point.  There's no understanding an outright refusal to support ALL of your users via a simple checkbox for an option that's already builtin.
(In reply to comment #71)
> This is a design decision, and some of those decisions will be unpopular.
> Sorry. There are add-ons to scratch your particular itch.  As has been pointed
> out (see comment 61) this is the behaviour that exists across all browsers. I
> don't think comparisons to MDI UIs are valid, as most MDI UIs have a "shell" in
> which sub windows are contained. We don't.

Let me repeat what I wrote in comment #61 (which you seem to have ignored):

> The only people it affects are people who are used to and who depend 
> on the old behaviour.  Anyone who was not already using the old 
> behaviour is unlikely to use the new behaviour either, so there is 
> no advantage in the change.
>
> The people who use keyboard shortcuts in Firefox are being 
> penalised, to nobody else's benefit.

If it is a design decision, please explain and justify that design decision.  In other words, explain which users it benefits and what that benefit actually is!
(In reply to comment #71)
> Sorry. There are add-ons to scratch your particular itch.  As has been pointed
> out (see comment 61) this is the behaviour that exists across all browsers. I

It seems you rely on usage studies done by other companies. Was there a huge demand to fix "last tab doesn't close the browser window"? Users all over globe were furious to get it fixed.

Good to know about the behavior of those browsers, one more reason not to use them.
> This is a design decision, and some of those decisions will be unpopular.

What is the basis of this design decision?

> Sorry. There are add-ons to scratch your particular itch.

What addons do or don't do is irrelevant to this issue.

> As has been pointed
> out (see comment 61) this is the behaviour that exists across all browsers.

So this was done out of some attempt to conform?

> Absolutely not. Less preferences, more customization through third party
> add-ons, please.

That is a somewhat ironic statement, since this is a case of less preferences, more customization through patching.

> You need to understand that most users do not find this
> disturbing, and indeed don't really run into the problem

So what was the reason to change it if most users don't care?

> I'm sorry that you do, I honestly am.

Whether you are sorry or not it irrelevant to the discussion.

> I need to build a browser that's best for most people, not
> specifically the 61 people who commented on this bug.

How is not having a close button beneficial to [firefox users] - 61 peopele?

> Thanks for your patience and understanding.

This is a disingenuous nicety, as there is no understanding being shown by those involved in this change. The resolution thus far has been "it has been decided, move along". Please forgo the niceties and present the factual arguments involved that necessitated this change.
Eu acho que esse firefox estΓ‘ virando um lixo, porque primeiramente nΓ£o aceitam conselhos do pessoal que estΓ‘ usando; em segundo lugar porque nΓ£o respeitam as opiniΓ΅es, baseando-se apenas em DESIGN.

Isso Γ© ridΓ­culo. Um navegador que quer ter sucesso, precisa ser voltado Γ s pessoas que podem fazer do mesmo um sucesso. Quem Γ© daqui da lista que vai indicar um navegador que nΓ£o faz jus aos seus usuΓ‘rios? Espero que ninguΓ©m.

Eu estou usando atualmente o OPERA, e estou bem feliz com ele, principalmente na questΓ£o DESIGN. Ele nΓ£o deixa nada a desejar.
Obviamente tem alguns pontos que ainda nΓ£o estΓ£o 100%, mas tenho certeza que isso se ajusta.

Programadores, procurem soluçáes naqueles que estão tentando ajudar, e não naqueles que querem somente deixar o navegador mais "bonitinho".

Se quiserem, leiam em portuguΓͺs mesmo, senΓ£o problema de vocΓͺs.
Ultimately, no design decision is ever going to be mathematically provable.  Anyone who wants some sort of objective justification for all design decisions will be sorely disappointed by a great many of our choices.  I think we're willing to live with that, and ultimately, this project is not and will never be a democracy.  We're going to make what we feel are the right choices for users.

This behaviour actually matches what we shipped in Firefox 1.0 and 1.5, and only changed for 2.0 for the "tab bar always on" case, which was not the default.  Was this based on "science" or "surveys" or any objective measure?  No, not really, it was something we were trying out (this was something I pushed for myself, and maybe even implemented myself, it was > 3 years ago).  That change was, perhaps, equally as controversial (see bug 341067 for the complete antithesis of this bug, among others) and frustrating to an entirely different set of users.  And yet, when we kept the behaviour, other people learned to like it.  However, for the vast majority of users of the product, there was _no_ change since Firefox first shipped.  i.e. Ctrl+W when down to one (hidden) tab has _always_ closed the browser window in the default configuration.

Fast forward to Firefox 3.5, where we decided that showing the tab bar at all times was the better choice for users, based on a number of reasons.  Now we have a collision between expected behaviour for two groups: those who already care about this behaviour (almost certainly a minority, given that it's not the default) and everyone else who have never flipped this pref (as well as anyone using any competing product).  One of those groups is going to have a behavioural change, and we chose the option that was the least disruptive to the largest number of users, and remained completely consistent with the default behaviour for _all_ versions of Firefox to date.

There's a pref (browser.tabs.closeWindowWithLastTab in about:config) for people to use to get this behaviour (regardless of their tabbar setting).  I think that's sufficient for users who really can't live without this behaviour.
Status: RESOLVED → VERIFIED
> Fast forward to Firefox 3.5, where we decided that showing the tab bar at all
> times was the better choice for users, based on a number of reasons.

Could you point me to somewhere where these reasons are discussed in detail?
 
> There's a pref (browser.tabs.closeWindowWithLastTab in about:config) for people
> to use to get this behaviour (regardless of their tabbar setting).  I think
> that's sufficient for users who really can't live without this behaviour.

This setting does not return the old behavior.
(In reply to comment #79)

Mike, thanks for taking the time to explain; the decision seems reasonable to me now.  IMO, it would have saved some trouble to give the explanation along with the initial WONTFIX resolution.
(In reply to comment #79)
> We're going to make what we feel are the right choices for
> users.

It's good to know important UI decisions are based on feeling of some selected individuals for which complaining is not allowed or encouraged.
(In reply to comment #82)
> It's good to know important UI decisions are based on feeling of some selected
> individuals for which complaining is not allowed or encouraged.

We absorb criticism and complaints from lots of sources.  Some we act on, some we don't.  Just because we disagree with arguments doesn't mean we don't read or allow them.  (Indeed, the simple fact that both beltzner and I have replied in this bug entirely disproves that idea.)

You're falling into the classic trap of "I have a strong opinion, and refusal to do this my way means I'm being ignored."  We listened, and decided we made the right call in the first place.  You're obviously not going to be happy with that outcome, but attacking individuals isn't going to do anything except make you look like a troll.
(In reply to comment #83)
> to do this my way means I'm being ignored."  We listened, and decided we made
> the right call in the first place.  You're obviously not going to be happy with
> that outcome, but attacking individuals isn't going to do anything except make
> you look like a troll.

It's difficult to understand the listening part when there's no evidence of taking anything "scientific" into an account when making it. Who have you listened to? I don't know you or the other Mike and I don't criticize either him or you but the decision you make.

The reason to revert the function to be the same as for FF2 has been clearly explained with benefits outweighing the possible drawbacks in my opinion. Best reason for current behavior seems to be because it's "by design". That is my current impression anyway.

So yes maybe I'm a troll, but this bug is already invalid/wontfix so who does some venting here harm? Who loses if proper explanation about the reasons and source for the current behavior is given? So yes, maybe I'm blind passionate troll as I don't see any valid reason for the current way.
>The reason to revert the function to be the same as for FF2 has been clearly
>explained with benefits outweighing the possible drawbacks in my opinion.

I second that. Modifying the behaviour of one aspect of a software product which has such a large user base violates the Principle of Least Astonishment. IMHO, this 'design' change is justified only if it fixes a crucial bug, which it does not, as far as I can see.
I would like to remind everyone of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html please read it. 

Panu I'm afraid you are making comments which have already been addressed, e.g:
> It's difficult to understand the listening part when there's no evidence of
> taking anything "scientific" into an account when making it.

Was already addressed when Mike said:
> Ultimately, no design decision is ever going to be mathematically provable. 
> Anyone who wants some sort of objective justification for all design decisions
> will be sorely disappointed by a great many of our choices.  I think we're
> willing to live with that, and ultimately, this project is not and will never
> be a democracy.  We're going to make what we feel are the right choices for
> users.

And when you say:
> So yes maybe I'm a troll, but this bug is already invalid/wontfix so who does
> some venting here harm? 

Well for starters you are filling up my inbox with your venting and opinion! I would be highly appreciative if you added actual constructive arguments, but the attitude of "that's not the way I like it" isn't going to get you anywhere. Perhaps you want to step back and really analyse your argument. A good place to start would be constructively establishing why Mike is wrong when he says:
> Now we
> have a collision between expected behaviour for two groups: those who already
> care about this behaviour (almost certainly a minority, given that it's not the
> default) and everyone else who have never flipped this pref (as well as anyone
> using any competing product).  One of those groups is going to have a
> behavioural change, and we chose the option that was the least disruptive to
> the largest number of users, and remained completely consistent with the
> default behaviour for _all_ versions of Firefox to date.

I wholeheartedly agree with him! You've said nothing to constructively demonstrate he is wrong. I've been in your position myself, arguing a point in the far more controversial bug 400495 and I found people who kept spamming the bug with "But I like it this way" detracted from the overall argument.
(In reply to comment #86)

First of all, sorry about the spam.

> Panu I'm afraid you are making comments which have already been addressed, 

Well I saw Mike's reply to this bug today, for which I replied. That reply didn't give any enlightenment about the reasons behind the decision.

> And when you say:
> > So yes maybe I'm a troll, but this bug is already invalid/wontfix so who does
> > some venting here harm? 
> 
> Well for starters you are filling up my inbox with your venting and opinion! I

Well sorry, I do not know where else to complain. I have gotten more than 2 messages to my inbox about updates of people removing themselves from this bug. This is my last message to this bug, as resistance seems futile.

> I wholeheartedly agree with him! You've said nothing to constructively
> demonstrate he is wrong. I've been in your position myself, arguing a point in

I did not want to say the same things again what has already been said better than me and my english could have ever said. I think everything possible about fixing  this bug has already been said, I really can't think anything that would change developers' minds. I don't know, maybe it's me who has to point they are wrong and not vice versa?

I can only speak for myself, and people who's computer & browser usage I have to follow or assist. Someone mentioned "make computer explode" button - and I can agree this if anything is that based on for example my mothers firefox usage (who now has tab mix plus installed).

- she doesn't understand what tabs are so I made the tab bar always visible
- she has difficulties hitting the tab close button so she closes them with middle click or ctrl-w as it's easier to hit the tabs than the close button.
- she knows to close programs from upper right
- if something unexpected happens she is lost, she will try to locate the browser window which isn't there.

I donΓ€t know if my mother would be a average user or not, but after FF2 her browsing was not as easy as it could have been.

Also I think this bug should be fixed based on full screen usage problems alone.
The scope of this bug should cover Seamonkey 2.x and Thunderbird 3.x as well.

Ctrl-W closes the entire application on both, not only Firefox.

The well established convention is that Ctrl-W closes child windows/tabs and Ctrl-X and/or Ctrl-Q closes the application. At least that's the convetion I see in all other software I've seen.

I don't understand why Mozilla apps have to contradict this, as per this bug.
1. Open a lot of tabs while browsing
2. Make sure a lot of JavaScript is running ;)
2. Hit Ctrl-w rapidly to close them
3. Can you track the opened tabs while, rapidly closing all but one??
4. The browser's responsiveness can't track it any more, sure as hell I can't either!
5. (waiting for a response)
6. Damn! Too late! Browser closed!

But in the file menu its says "Close tab" for Ctrl-w. When is this feature ever going to be corrected??
(In reply to nomiz from comment #93)
1. Start the browser with one tab.
2. Try to close the tab ("Close tab" is Ctrl+W)
3. Tab doesn't get closed, it only gets blanked.
4. Go to step 2.

The default setting of browser.tabs.closeWindowWithLastTab (in about:config) avoids this endless loop, and it's by design. If you still want never to close the window by hitting only Ctrl+W (but only by Ctrl+Shift+W), then you can set the preference to false (by double-clicking the about:config line). Easy as snapping fingers.

See also comment #79.
(In reply to Tony Mechelynck [:tonymec] from comment #96)
> (In reply to nomiz from comment #93)
> 1. Start the browser with one tab.
> 2. Try to close the tab ("Close tab" is Ctrl+W)
> 3. Tab doesn't get closed, it only gets blanked.
> 4. Go to step 2.
> 
> The default setting of browser.tabs.closeWindowWithLastTab (in about:config)
> avoids this endless loop, and it's by design. If you still want never to
> close the window by hitting only Ctrl+W (but only by Ctrl+Shift+W), then you
> can set the preference to false (by double-clicking the about:config line).
> Easy as snapping fingers.
> 
> See also comment #79.

This is an entirely a learned behaviour -- there is no valid expectation that closing a subc-component of an application (in this case a tab) should cause the application itself to exit -- especially considering that than the exiting of a browser typically has consequences, such as the ending of sessions.

And having to go into about:config is not easy as snapping ones fingers -- the developers obviously didn't think it was, or they wouldn't have a warning that comes up when you try to go there.
(In reply to Tony Mechelynck [:tonymec] from comment #96)
> Easy as snapping fingers.

Maybe, for geeks. Definitely not for non-geeks. A browser that's supposed to have (and does have) widespread acceptance can do better than having a non-technical user type about:config and set the value of a variable. 

Also see https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Exactly why is this closed as Invalid?
Hrishikesh Barua said it perfectly in https://bugzilla.mozilla.org/show_bug.cgi?id=456405#c98

I vote REOPEN.
Was entering text, 6 paragraphs worth, then bumped control-W... BAM!  Window gone, browser gone.  Restart
Firefox, restore session--nicely gives me a blank form, and I get to start all over again.

Really?  In 2014 a stray key will throw all your work away and shut down the browser?  No option to rebind
the key?  No option to maybe... ASK?  Really?  Howsabout if you're going to hair-trigger on a keystroke and
blow your brains out, at least go to the trouble of saving ALL the content of the web page you're about to trash?
But, honestly, who writes apps in this day and age that throw away user work based on a single, unconfirmed
keystroke.  Give me a break.
(In reply to Andrew Valencia from comment #100)
> Was entering text, 6 paragraphs worth, then bumped control-W... BAM!  Window
> gone, browser gone.  Restart
> Firefox, restore session--nicely gives me a blank form, and I get to start
> all over again.
> 
> Really?  In 2014 a stray key will throw all your work away and shut down the
> browser?  No option to rebind
> the key?  No option to maybe... ASK?  Really?  Howsabout if you're going to
> hair-trigger on a keystroke and
> blow your brains out, at least go to the trouble of saving ALL the content
> of the web page you're about to trash?
> But, honestly, who writes apps in this day and age that throw away user work
> based on a single, unconfirmed
> keystroke.  Give me a break.

Instead of whining, toggle browser.tabs.closeWindowWithLastTab to false in about:config (it's a boolean, double-clicking toggles it) as comment #21 and #22 from November 2008 already suggested it.
Whiteboard: [see comment #21 and #22]
(In reply to Tony Mechelynck [:tonymec] from comment #101)
> Instead of whining, toggle browser.tabs.closeWindowWithLastTab to false in
> about:config (it's a boolean, double-clicking toggles it) as comment #21 and
> #22 from November 2008 already suggested it.

You seem to have completely missed the point here, and are targeting specific comments with condescending responses. Do you have any rational, technically and UX-wise valid response to the numerous points raised above? Don't you think that if so many users have raised this point, there might really something that can be improved?
"We believe that if you put the user front and center, you can make every experience for them richer and more meaningful. " Darren Herman, VP of Content Services, Mozilla.

Either Mozilla wants Firefox to be(come) a great app development platform or it doesn't. As Andrew Valencia so aptly and succinctly put it, "In 2014 a stray key will throw all your work away and shut down the browser?" ... it's simply NOT good enough.

@Tony Mechelynck: instead of whining at users, and people that take time out of their day to try to help, take it up with your VP of Content Services and explain to him why he's wrong and why you think defending the indefensible is more important than improving the UX.
Instead of copping attitude, why not consider making the default human friendly, and leave
the about:config boolean toggling for people who like UX-hostile behavior?
The latest commenters above seem to believe that I am a Mozilla employee: I'm not. I am just a user, and sometimes, in my free time, I do volunteer QA work for SeaMonkey.

"User-friendly" is subjective. When I close a window, I want it to close, not remain blank; and if it is the last window, I want the application to go away. You are of the opposite persuasion. So far so good. For some reason, the developers decided (without asking me) that "closing the application when the last window gets closed" was the right default, yet they defined a preference which can be toggled to get the opposite behaviour. So AFAIK this bug was RESOLVED INVALID in 2009 and VERIFIED later the same day because it was "not a bug, but intended behaviour". Anyone for whom toggling the preference manually is not good enough is free to write (or have someone write) and install β€” and, why not, distribute β€” an extension to change the default. It is possible. I'm not interested in doing it myself because, among other reasons and as said above, the current defaut is the behaviour I prefer.
(In reply to Tony Mechelynck [:tonymec] from comment #105)
> "User-friendly" is subjective. When I close a window, I want it to close,
> not remain blank; and if it is the last window, I want the application to go

I think that a point has already been raised, that the tabs inside the browser are not individual browser "windows" but the tabs represent MDI interface, tab is a document. So browser is a window which holds multiple documents. I can't remember any other MDI program that closes itself when the last document is closed. I don't care about this bug so much, as it's the first setting I reverse with addon after I install Firefox, I just follow this bug out of interest how long this kind of madness is able to continue.

It would be interesting to know, what platform is used if one thinks the current default is the right one.
Hi newcomers,

I'd encourage you all to read comment 79 for the history and rationale behind this behaviour.  I'd also note that this behaviour matches the current behaviour of every other major browser, as well as the default behaviour of Firefox since the beginning, so a change would break expectations for far more users than it would help.

We've had the MDI argument, the consistency argument, and a half dozen other arguments about this over a number of bugs.  I haven't seen a new rationale in five years, so at this point I'm going to restrict commenting instead of continuing to rehash past discussions ad nauseam.  Email me if you think I missed a new argument that we haven't already considered and would justify overcoming a decade of consistency among major browsers.

As for comment 100, the core issue has nothing to do with this bug, as if session restore wasn't tracking the form contents that would be true regardless of whether the window itself closes.  SSL sites that set no-cache or other headers that session restore respects (so as to not store, unprotected, sensitive data entered in forms) should use onbeforeunload to warn the user before closing or otherwise navigating away from the page.
Restrict Comments: true
Since I typed this up on an email thread: here’s the summation of how, when I evaluate the situation, I continue to reach the same conclusion:
 
Assumptions (most based on studies we’ve done and/or broadly documented user tendencies)
 
* Users learn to ignore dialogs over time.  The more a dialog is β€œroutine” the more they tend to acquire a muscle memory to β€œfinish” their task instead of responding to dialogs. (This is why Undo is generally recommended instead of modal confirmations in design guidelines.)
* As a corollary: dialogs are most effective when they are unexpected, causing a cognitive interrupt.  (There’s a lot of automatic dismissal of warning dialogs even in this context, it’s just relatively better.)
* Session restore is β€œgood enough” for the vast majority of close tab cases (which is why we don’t force the user to confirm _every_ tab closure, and you’re not arguing for that)
* Most tabs do not contain unsaved data (content consumption remains much more prevalent than production)
* Most modern web apps use a mix of autosave and state transition/keystroke detection already to prevent unintentional navigation
* Most tab close actions are _intentional_ on the part of the user
 
Where this all nets out is that a dialog would be a broad brush that would only be useful enough to interrupt the user if ALL of the following are true:
 
* the action wasn’t intentional
* there is data that isn’t saved by the web app
* session restore won’t restore the entered data (cache headers or oddball widgets)
* the page wasn’t smart enough to detect unsaved state and prompt the user itself
 
In all other cases, it’s just an obstacle to closing the window.  Once a user acquires the habit of ignoring the warning (and cognitive science suggests they will), when they actually stumble into that situation, they’re not likely to gain any benefit because they won’t even read the dialog.  At that point, all you’ve done is make your product more annoying to use, without gaining enough user benefit to justify it.
You need to log in before you can comment on or make changes to this bug.