455852 - Add a hidden pref for not closing the window with the last tab

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Daniel C]

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.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Mike, would you please elaborate on the reason of implementation of the proposal stated by you here:
https://bugzilla.mozilla.org/show_bug.cgi?id=392870#c1 (point b))

my opinion: it's not intuitive, GC does *not* count, this shouldn't be moved to extensionland (https://bugzilla.mozilla.org/show_bug.cgi?id=392870#c44)
thank you.

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

as addition to Dão's non-comprehensible bug morphing step: this shouldn't be moved to hidden pref land either :-/

Comment 3

[Danny]

I agree there must be such pref in about:config or even in 'Options' dialog. IMO closing the whole program with the last tab is very annoying and is not intuitive at all.

Comment 4

[Daniel C]

The reasons I liked the behaviour prior to today:

If you had a lot of tabs you wanted closing, holding Ctrl+W would do that for you without closing the window.

If you want to close the last tab because it is hogging the CPU/network but want to keep the window open.

If you accidentally close the tab, or close the tab intentionally but realise that you shouldn't have done, Undo Close Tab no longer gets it back for you because the window has gone.

If you just like to keep a window open with no tabs loaded because that way you can start browsing immediately without waiting for the browser to startup.

If we go the way of Opera/Chrome and make about:blank useful (search bar, links to home page & most visited etc.) then blanking the last tab will be a quick way to get to those things.

This has been the behaviour in Firefox 2 & 3 and will be annoying and confusing for people who have become accustomed to it when they upgrade to Firefox 3.1. Not all of these people should need the knowledge to create/change a hidden preference.

Comment 5

[philippe (part-time)]

From a Mac user perspective, the new 'behaviour' is definitely foreign. All other tab-aware apps (with the exception of Opera, another foreign duckling) disable (like Camino) or hide the close button on the tab (Ex. Safari or SubEthaEdit, Transmit) when only one tab is open.

If the (Mac) user wants to close the window at that stage, either cmd-W or the close window widget on the Window title bar is the normal, expected behaviour.

At least, you don't quit the app from under me :-/

(and if that behaviour is here to stay, I'll vote for _not_ making this a hidden pref. That's bad UI, dixit M Connor in [1]).


[1] http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/457b9017eeddee26/2b126b0b4bac15c9#2b126b0b4bac15c9

Comment 6

[Dão Gottwald [:dao]]

Once the hidden pref is there, you can file bugs about the default setting and a visible pref at your will.

(In reply to comment #5)
> Mac [..] All other tab-aware apps [..] hide the close button on the tab
> [..] when only one tab is open.

File a theme bug?

Comment 7

[philippe (part-time)]

(In reply to comment #6)
 
> (In reply to comment #5)
> > Mac [..] All other tab-aware apps [..] hide the close button on the tab
> > [..] when only one tab is open.
> 
> File a theme bug?

Done -->  bug 455990.

Comment 8

[u88484]

It is funny how Dao never responds to comments that greatly explain why his some of his thoughts suck in terms on usability.

Dao, read comment #4 and think about it before commenting back for once.  You always get some idea in your head and you are one stubborn person and rarely go back on anything you first decide on...even when there are a million reasons to do so.  Comment #4 made six great points and you completely ignored the entire post.

Comment 9

[Mike]

I don't like many tabs and always "clean" last loaded page by "closing" last tab (before bug 392870). Now it is very annoying that browser unintentionally closes.

Comment 10

[Tom Levels]

This really is an annoying bug, I cannot think of a reason to keep this behaviour (but a lot why it should be removed).

Comment 11

[u88484]

I also don't understand why Dao morph this "Closing last tab closes window instead of blanking it" regression bug into "Add a hidden pref for not closing the window with the last tab" bug.  This bug was filed for the purpose of making it default that the window does not close when closing the last tab not creating a hidden pref that most users won't find in order to achieve this behavior.  Also, what does the tooltip say when hovering over the 'X' button?  It doesn't say "Close Window".

Comment 12

[Dão Gottwald [:dao]]

(In reply to comment #11)
> I also don't understand why Dao morph this "Closing last tab closes window
> instead of blanking it" regression bug into "Add a hidden pref for not closing
> the window with the last tab" bug.

Because that's what I'm implementing. But feel free to take the bug.

> Also, what does the tooltip say when hovering over the 'X' button? 
> It doesn't say "Close Window".

It doesn't say "close tab and open blank tab" either. The window only consists of that single tab, so closing the window is more intuitive to *new* users -- which was the goal of bug 392870, and doesn't necessarily include you or me.

Comment 13

[u88484]

(In reply to comment #12)
> (In reply to comment #11)
> > I also don't understand why Dao morph this "Closing last tab closes window
> > instead of blanking it" regression bug into "Add a hidden pref for not closing
> > the window with the last tab" bug.
> Because that's what I'm implementing. But feel free to take the bug.

You caused the regression in usability though.

> > Also, what does the tooltip say when hovering over the 'X' button? 
> > It doesn't say "Close Window".
> It doesn't say "close tab and open blank tab" either. The window only consists
> of that single tab, so closing the window is more intuitive to *new* users --
> which was the goal of bug 392870, and doesn't necessarily include you or me.

The goal of bug 392870 was "Easy discoverability of Tabbed Browsing for new users" not easy discoverability and how to piss of new and old users by closing the window when clicking the closed tab button on the last tab open.  The button lies on the tab.  The tooltip says close tab not close window.  The close button in the top right on the window is there to close the window, not the tab close button.  Clicking on the button should not close the window.

And you still failed to address the comments in comment #4.  Great reasons on why closing the window sucks and I guess you don't have a rebuttal for any of those reason or are completely ignoring the comment because you agree inside but seem to never go back on anything once you have made a decision.

Comment 14

[u88484]

And adding a hidden pref is just a band-aid.  All I'm asking is that some more thought go into this instead of just adding a hidden pref to advoid an issue.

Comment 15

[Dão Gottwald [:dao]]

As I said in comment 6, a hidden pref is the first step if you want a visible pref and/or a different default behavior. Anyway, I think I can agree with you that I suck. No need to add another useless comment.

Comment 16

[RFLazaro]

Since you agree that this sucks why don't you backout your change until you find a compromise between "easy discoverability for new users" and "not **** of existing users".

What this bug is doing right now is creating a solution to a problem that didn't exist in the first place.

Comment 17

[u88484]

At least add a notification that closing the tab will close the window and ask if that is really what they wanted to do.  Which may already be the case but I don't and won't set the pref because I don't want to be nagged when I click the button that is actually supposed to close the window.  The notification and a hidden pref should suffice for most users although comment #4 makes very good points.

> If you had a lot of tabs you wanted closing, holding Ctrl+W would do that for
> you without closing the window.
Would get a notification with my suggestion

> If you want to close the last tab because it is hogging the CPU/network but
> want to keep the window open.
Won't help this issue

> If you accidentally close the tab, or close the tab intentionally but realise
> that you shouldn't have done, Undo Close Tab no longer gets it back for you
> because the window has gone.
The notification would help slightly in that you won't accidently close the tab and window.

> If you just like to keep a window open with no tabs loaded because that wayyou
> can start browsing immediately without waiting for the browser to startup.
Won't help here except for if about:blank is the homepage but that would have been the default anyways per that comment

> If we go the way of Opera/Chrome and make about:blank useful (search bar,links
> to home page & most visited etc.) then blanking the last tab will be a quick
> way to get to those things.
Won't help this but maybe we will get something like this one day.

Comment 18

[Radek 'sysKin' Czyz]

I would like to agree that adding hidden prefs serves no purpose other than to silence critics. It doesn't help anyone but our small group who knows about it, and it adds complexity to achieve that.

IMHO last tab should simply be not closable. Since bug 455990 already covers the close button, all remains is for keyboard shortcuts to follow the button, and this bug then covers an action that's not even possible.

Comment 19

[RFLazaro]

Why don't we fix the discoverability issue by following Windows Live Toolbar - Tabs where it defaults to a page describing what tabs are and how to use them. See link for screenshots https://bugzilla.mozilla.org/attachment.cgi?id=339466

Comment 20

[(mostly gone) XtC4UaLL [:xtc4uall]]

for the sake of open processes (hello usenet post, hello wiki, anyone?) in introducing new UI behavior i'd like hear finally a comment from the Fx drivers on this topic, especially to comment 1 & comment 4.

we all know that once a hidden pref is been introduced, filling bugs to provide an UI option and/or for demanding the old behavior will get WONTFIXED.

this smells so sneaky.

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Basically, I agree to comment 18, the last tab should not be closed by any actions.

But users can close the last tab in current our design and the window which is the *owner* of the last tab is also killed by it. However, the window has non-tab managed information, e.g., recently closed tabs. Looks like this behavior is strange for many people. However, some users may want to close the window by the last tab closing.

I suggest that the new pref should have "need_to_confirm" state in its value, like "Warn me hen closing multiple tabs". I.e., when users are closing the last tab, Fx should confirm the user wanted behavior -- closing only tab, closing window or cancel the action --. I think this confirming approach makes all people happy.

Comment 22

[YUKI "Piro" Hiroshi]

I agree to Masayuki's idea at comment 21. Confirming to users about the behavior on the first time seems better for beginners, than the fixed behavior introduced by bug 392870 or a hidden pref for Firefox geeks.

Comment 23

[YUKI "Piro" Hiroshi]

If you change the behavior of last-tab-closing, in parallel, I think we should re-design Firefox's UI under just one designing policy, to re-create mental models in users' mind and reduce confusions. The new behavior doesn't match to the current design as Masayuki said.

Comment 24

[Ian]

Use case fro keeping ff open when last is closed

I am going through email opening messages and clicking links, read mail and links, close messages and related tabs.  Move to next action item.

If ff closes then it breaks the work flow.

Comment 25

[Bill Gianopoulos [:WG9s]]

I find myself particularly susceptible to accidentally closing the browser following changing any preference via about:config and then closing the tab.  I was about to file a bug about the browser arbitrarily crashing with no crashreproter after changing things with about:config before I realized what was happening.

Comment 26

[Mike]

(In reply to comment #18)
> IMHO last tab should simply be not closable. Since bug 455990 already covers
> the close button, all remains is for keyboard shortcuts to follow the button,
> and this bug then covers an action that's not even possible.
Indeed, all modern browsers have no close button on last tab.
Then maybe hidden pref to keep old behavior of last tab?

Comment 27

[Wesley Johnston (:wesj)]

(In reply to comment #12)
> Because that's what I'm implementing. But feel free to take the bug.

Can I just #ifdef the relevant code to only happen on OSX? There's really no need for a pref here that I can think of. Nobody but OSX is asking for this behavior (nor is it expected behavior by most of their users I think).

Applications shouldn't shut down just because they have no open documents. That's true on every single platform I think.

Comment 28

[Martijn Wargers (dead)]

Attachment: patch

Comment 29

[Martijn Wargers (dead)]

Attachment: patch as an extension

This is a windows only extension, don't use it when you're on a mac.

Comment 30

[Dão Gottwald [:dao]]

Comment on attachment 339754 [details] [diff] [review]
patch

This regresses part of bug 392870 comment 1. I don't know of any statement from Beltzner or Connor that we want to do that. Instead, I think we want to make the current behavior less overpowering.

Comment 31

[Martijn Wargers (dead)]

I disagree with bug 392870 comment 1 part b.

I also think that morphing this bug into a different one was a bad idea. There is now no bug about the fact that a lot of people don't like the bug 392870 comment 1 part b

Comment 32

[philippe (part-time)]

Dão,
Is there anywhere a document that outlines the changes of bug 392870 comment 1 (b) in a larger context/goal? Because at the moment, it looks more like: lets try something here, then something there, patch that all up, repair it again, and we'll end up with an unworkable UI that doesn't fit anywhere on any platform (back to Fx 2 ?).

I agree with Martijn btw (see also my comment 5 above), and lots of people are unhappy, seeing the number of votes + CC here and in bug 455990.

Comment 33

[Dão Gottwald [:dao]]

(In reply to comment #32)
> Dão,
> Is there anywhere a document that outlines the changes of bug 392870 comment 1
> (b) in a larger context/goal?

The goal, which I think is large enough and many tend to forget seemingly, is to make tabbed browsing discoverable and therefore more intuitive for all users. The question what to do when the user closes the last tab is a new one. Before bug 392870, it was mainly about users that intentionally set browser.tabs.autoHide to false. Now that this pref defaults to false, the answer is most likely not to simply go back to as it was.

Comment 34

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

First and foremost: the fact that this bug exists is enough to register objection, please avoid from piling on to Dao or adding "I don't like this either" comments.

Bug 392870 is primarily about showing the tab strip by default. If there is disagreement about that idea, it needs a new bug. I am assuming that people are OK with the fundamental of showing the tab strip by default for the purposes of this comment.

Once the tabstrip is shown by default, the behaviour of closing a single tab needs to be resolved; the existing Firefox 3 behaviour was allowed because it was a user-mode, not because it was valued as an interaction. Clicking the close button on a tab should result in that tab closing; the behaviour had been making it look like Firefox wasn't responding to UI events. While I acknowledge that there are some specialized workflows (as mentioned in comments in this bug and elsewhere) those are not primary use cases as far as I'm concerned, and Dao's right, best handled by an about:config tweak that allows users to retain their old behaviour of holding open the window when the final tab is closed.

Contrary to some allusions in this bug, the "closing-last-tab-closes-window" behaviour is not actually out of line with other Windows based browsers. IE8, Safari and Chrome all close the application when the last tab is closed. Bug 455990 (removing the close button from the final tab) completes the parity with IE8 and Safari, and seems like the right idea (though Chrome doesn't do this), but no browser goes as far as suggested in comment 18 (disable the keyboard shortcut for closing a single tab when that will close the application).

Bug 394759 is about undoing a close window action, and will help in the case where a user accidentally or overzealously hits ctrl/cmd-w and closes the window. We can probably also do some things where if we notice that there's a bunch of ctrl/cmd+w keypresses, we dispose of some of them such that the window stays open (since we have ctrl/cmd+shift+w to close a window full of tabs). That again would need another bug.

Comment 35

[Bill Gianopoulos [:WG9s]]

(In reply to comment #34)
> Contrary to some allusions in this bug, the "closing-last-tab-closes-window"
> behaviour is not actually out of line with other Windows based browsers. IE8,
> Safari and Chrome all close the application when the last tab is closed. Bug

1. By default, the windows version of Safari dows not show the tab bar when only one tab is open.

2. Even if you alter this setting so that it does, if there is only one tab open, that tab does not have a close button, therefore it is impossible to accidentally close the application by use of such a button.

Removing the close button in the case where only one tab is open, which seems to be consistant with Safari and IE7, would seem to make more sense to me than having a close tab button which ends up closing the entire application.  The latter action makes no sense (at least to me it doesn't).

I am sure the current behavior will result in filing of numerous bugs about Firefox unexpectedly crashing without launching crashreporter.  I know this because I almost filed such a bug.

Comment 36

[Dão Gottwald [:dao]]

Attachment: patch

Using BrowserOpenTab fixes bug 425375.
"return null" was a copy&paste mistake -- _endRemoveTab doesn't have return value.

Comment 37

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/dcb55e794dd5

Comment 38

[YUKI "Piro" Hiroshi]

> Bug 394759 is about undoing a close window action, and will help in the case
> where a user accidentally or overzealously hits ctrl/cmd-w and closes the
> window.

You don't think about users on Windows and Linux. On Mac OS X, there is the menu bar to choose the menu even if there is no window, but, on Windows or Linux, "close last window" just means "quit the application". If I accidentally quit Firefox, restarting it takes much time because I installed many extensions. It seems Mac-specific idea.

Comment 39

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

(In reply to comment #35)
> Removing the close button in the case where only one tab is open, which seems
> to be consistant with Safari and IE7, would seem to make more sense to me than

Yes, which is why I explicitly stated that there was bug 455990 to bring us up to parity there; please take the time to read my entire comment before replying.

(In reply to comment #38)
> You don't think about users on Windows and Linux. On Mac OS X, there is the
> menu bar to choose the menu even if there is no window, but, on Windows or
> Linux, "close last window" just means "quit the application". If I accidentally
> quit Firefox, restarting it takes much time because I installed many
> extensions. It seems Mac-specific idea.

I very much *do* think about users on Windows and Linux, actually. That's why I mentioned the undo close window bug (see bug 394759) and the potential for adding an algorithm to prevent someone from holding down Ctrl-W and accidentally closing their browser.

Comment 40

[Martijn Wargers (dead)]

(In reply to comment #34)
> Contrary to some allusions in this bug, the "closing-last-tab-closes-window"
> behaviour is not actually out of line with other Windows based browsers. IE8,
> Safari and Chrome all close the application when the last tab is closed. 

Not here on my machine (using Windows XP). IE8 doesn't do anything when middle-clicking the last tab and Safari is hiding the tab-strip when only one tab is available.

Comment 41

[Martijn Wargers (dead)]

(In reply to comment #34)
> Bug 394759 is about undoing a close window action, and will help in the case
> where a user accidentally or overzealously hits ctrl/cmd-w and closes the
> window.

I don't see how that's related to this bug. When you've closed the last tab, you've closed the application in current trunk builds. There is no way to 'undo' that.

Comment 42

[Wesley Johnston (:wesj)]

I'm fine with disabling the close tab options everywhere. That's what Opera,
IE8, and Safari and several other MDI apps I have try to do. Opera has the
behavior I would really like where the last tab CAN be closed, and then is
replaced with their "blank" and close tab options are disabled everywhere. This
allows the user to say, "I'm done with that task, and now on to the next." In
Safari strangely, CTRL-W is attached to "Close Tab" until the instant when one
tab is open, and then it attaches to "Close Window" instead (can you say
confusing behavior?).

This was just about adding the pref though, which mangles code readability and
adds performance overhead. In the end I don't think we need special algorithms
to detect when CTRL-W is held down or anything. I stand by the statement that
closing the last document should never close the application on any operation
system (which doesn't conflict with "Clicking the close button on a tab should
result in that tab closing"). That could have been accomplished with a few simple ifdefs for OSX here. I honestly don't think the lack of a huge UI response when someone closes a tab that has both about:blank in it and no browser history warrants this much effort.

If you want to theme it differently, or disable some commands or something, go
ahead. But there was no reason to rip out code that's been tested and tried for
a couple years here. All it does is hamper workflow for users who aren't
expecting it, without adding any real benefit that I can see.

Comment 43

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

(In reply to comment #40)
> Not here on my machine (using Windows XP). IE8 doesn't do anything when
> middle-clicking the last tab and Safari is hiding the tab-strip when only one
> tab is available.

This bug has gotten incredibly fractured and gone off the rails.

Ctrl-W on the last tab in IE8 *does* close the window. That was what the allusion was about. There is no way to close the tab with a mouse click as the button is removed from the last tab. As I've stated multiple times, there's a bug to bring us to that level of parity.

(In reply to comment #41)
> I don't see how that's related to this bug. When you've closed the last tab,
> you've closed the application in current trunk builds. There is no way to
> 'undo' that.

Unless you have two windows open, at which point you've just closed that window with no undo-close-tab equivalent functionality as was available in the previous behaviour.

Comment 44

[Daniel C]

(In reply to comment #34)
> Clicking the
> close button on a tab should result in that tab closing; the behaviour had been
> making it look like Firefox wasn't responding to UI events.

I disagree with this. If I had a tab open with a page loaded in it, and I then clicked on the close tab button, that tab disappeared and was replaced by a new empty one. I can't see how this could be perceived as non-responsive. Could you explain this further please?

> Bug 394759 is about undoing a close window action, and will help in the case
> where a user accidentally or overzealously hits ctrl/cmd-w and closes the
> window.

An undo close window action is only useful when the window that has accidentally been closed is not the last window.

> We can probably also do some things where if we notice that there's a
> bunch of ctrl/cmd+w keypresses, we dispose of some of them such that the window
> stays open (since we have ctrl/cmd+shift+w to close a window full of tabs).

"Dispose of some of them" sounds vague and likely to be confusing.

Overall, I think that bug 392870 should have stuck to the tab bar issue (which I agree with) and not included the change which causes many users to think "Huh? Where did my browser just go?" when closing a tab. I realise that showing the tab bar when there is only 1 tab open has not been the default option in any release, but it was still an option in the main preferences UI and not just an about:config toggle. This means that while the majority of users probably have the default setting, more than a negligible amount will have changed it and it is those people that will be thouroughly confused when they upgrade to 3.1.

Comment 45

[Daniel C]

I wrote comment 44 before seeing comment 43 (in case you thought I'd ignored the undo close window part). With a sense of déjà vu I filed bug 456405.

Comment 46

[Martijn Wargers (dead)]

Attachment: patch

(In reply to comment #43)
> This bug has gotten incredibly fractured and gone off the rails.

Yes, unfortunately, that's what you get when you morph one bug into another.
Afaict, this bug was filed as the "Closing last tab closes window instead of blanking it" bug, but was morphed into this pref thing.

> Ctrl-W on the last tab in IE8 *does* close the window. That was what the
> allusion was about. There is no way to close the tab with a mouse click as the
> button is removed from the last tab. As I've stated multiple times, there's a
> bug to bring us to that level of parity.

Middle-clicking the last tab *doesn't* close the window. So if I understand you correctly, only ctrl-W should close the window when there is only one tab left? You're saying there is a bug filed for that? Which bug?
I've made a patch that implements this behavior (I'm attaching it to this bug for now, since I don't know of that other bug you mentioned).


> > I don't see how that's related to this bug. When you've closed the last tab,
> > you've closed the application in current trunk builds. There is no way to
> > 'undo' that.
> 
> Unless you have two windows open, at which point you've just closed that window
> with no undo-close-tab equivalent functionality as was available in the
> previous behaviour.

Ok, well, I don't use more than one Firefox window, since that's what tabs are for. The problem still stands that it has now become very easy to accidentally close Firefox completely.

Comment 47

[Bill Gianopoulos [:WG9s]]

(In reply to comment #39)
> (In reply to comment #35)
> > Removing the close button in the case where only one tab is open, which seems
> > to be consistant with Safari and IE7, would seem to make more sense to me than
> 
> Yes, which is why I explicitly stated that there was bug 455990 to bring us up
> to parity there; please take the time to read my entire comment before
> replying.

Comment 48

[Bill Gianopoulos [:WG9s]]

(In reply to comment #47)
> (In reply to comment #39)
> > (In reply to comment #35)
> > > Removing the close button in the case where only one tab is open, which seems
> > > to be consistant with Safari and IE7, would seem to make more sense to me than
> > 
> > Yes, which is why I explicitly stated that there was bug 455990 to bring us up
> > to parity there; please take the time to read my entire comment before
> > replying.

Hmm. I love bugzilla.

What I tried to say here was that the patch in bug 455990 does not bring us to parity with Safari and IE7 in this case.  They both disable the context menu choice to close the tab in this case also.

Comment 49

[Bill Gianopoulos [:WG9s]]

(In reply to comment #31)
> I disagree with bug 392870 comment 1 part b.
> 
> I also think that morphing this bug into a different one was a bad idea. There
> is now no bug about the fact that a lot of people don't like the bug 392870
> comment 1 part b

Actually really the bad idea was when the "make the tab browsing feature more discoverable" bug got morphed into a "while you are at it make it really easy for the user to screw up and accidentally close the entire application".  Just my opinion, I could be wrong.

Comment 50

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

Comment on attachment 339871 [details] [diff] [review]
patch

This looks like a patch for bug 456382 (which already has a patch).

Comment 51

[Martijn Wargers (dead)]

Ok, this bug depends on bug 456382 then.

Comment 52

[tabmix.onemen]

calling BrowserOpenTab from _beginRemoveTab don't play nice. the new blank tab selected before the old tab actually removed, we see the 2 tabs for a split moment....

     if (l == 1) {
       if (this.mPrefs.getBoolPref("browser.tabs.closeWindowWithLastTab")) {
         closeWindow(true);
         return null;
       }
-      BrowserOpenTab();
+      this.addTab("about:blank");
+      if (gURLBar)
+        gURLBar.focus();
       l++;
     }

Comment 53

[Dão Gottwald [:dao]]

(In reply to comment #52)
> calling BrowserOpenTab from _beginRemoveTab don't play nice. the new blank tab
> selected before the old tab actually removed, we see the 2 tabs for a split
> moment....
> 
>      if (l == 1) {
>        if (this.mPrefs.getBoolPref("browser.tabs.closeWindowWithLastTab")) {
>          closeWindow(true);
>          return null;
>        }
> -      BrowserOpenTab();
> +      this.addTab("about:blank");
> +      if (gURLBar)
> +        gURLBar.focus();
>        l++;
>      }

How would not selecting the new tab beforehand change the fact that you can see two tabs?

Comment 54

[Wesley Johnston (:wesj)]

(In reply to comment #43)
> Ctrl-W on the last tab in IE8 *does* close the window. That was what the
> allusion was about. There is no way to close the tab with a mouse click as the
> button is removed from the last tab. As I've stated multiple times, there's a
> bug to bring us to that level of parity.

IE8 also disabled the Close Tab option in the context menu when there's only one tab open. I think leaving it in the File menu (and leaving the keyboard shortcut) is just as likely a bug to them as it is a feature. I really think Opera's behavior is the correct one for Windows at least, but its being ignored.

Slightly OT: Really this feature was just implemented with almost zero planning, so now its fractured into sixteen different bugs, each one covering some of the thought that should have originally gone into it. Its not the fault of this bug or any of the others that that happened. They should all be backed out though, all the bugs closed, and the feature implemented once there's some sort of design document. This is just a mess now.

Comment 55

[Jay Rossiter]

I have to agree with comment 54's second point.  This change was not planned out at all, and it has simply turned into an outright mess.

Comment 56

[Dão Gottwald [:dao]]

I don't know what you mean. Right now there are no more than two alternatives ahead: bug 455990 / bug 456382 and bug 456425. The rest is Bugzilla noise. Please stop spreading FUD, and more importantly, abusing Bugzilla.

Comment 57

[morboon]

Please don't forget about bug 456405 as well.

Comment 58

[mitsugu oyama]

A lot of bugs of the same this content are flooded. I feel the necessity for setting "DUPLICATE" to the status of those bugs. How does you think?

Comment 59

[Matthew Knowlton]

(In reply to comment #21)
> Basically, I agree to comment 18, the last tab should not be closed by any
> actions.
> 
> But users can close the last tab in current our design and the window which is
> the *owner* of the last tab is also killed by it. However, the window has
> non-tab managed information, e.g., recently closed tabs. Looks like this
> behavior is strange for many people. However, some users may want to close the
> window by the last tab closing.
> 
> I suggest that the new pref should have "need_to_confirm" state in its value,
> like "Warn me hen closing multiple tabs". I.e., when users are closing the last
> tab, Fx should confirm the user wanted behavior -- closing only tab, closing
> window or cancel the action --. I think this confirming approach makes all
> people happy.

I vote for this solution

Comment 60

[Marcia Knous [:marcia]]

verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre.

Comment 61

[mitsugu oyama]

(In reply to comment #22)
> I agree to Masayuki's idea at comment 21. Confirming to users about the
> behavior on the first time seems better for beginners, than the fixed behavior
> introduced by bug 392870 or a hidden pref for Firefox geeks.
I think so.Now therefore,I agree Masayuki's idia at comment 21.

Comment 62

[Dão Gottwald [:dao]]

Test checked in:
http://hg.mozilla.org/mozilla-central/rev/bd315a993149

Comment 65

[vajorie]

In bug 501410 I wasn't talking about a hidden setting (which already is there in about:config), I was requesting a lost feature (regression) in 3.5 to be put back... Also, this is marked fixed (comment 60 confirms fixed) even though in 3.5 it's not.

Comment 66

[Mike Connor [:mconnor]]

The hidden pref works for me in 3.5.

Comment 68

[u88484]

(In reply to comment #65)
> In bug 501410 I wasn't talking about a hidden setting (which already is there
> in about:config), I was requesting a lost feature (regression) in 3.5 to be put
> back... Also, this is marked fixed (comment 60 confirms fixed) even though in
> 3.5 it's not.

Yes, I know but that is what this bug started out as and a decision was made to only include a hidden pref.

See the bug history, https://bugzilla.mozilla.org/show_activity.cgi?id=455852

Comment 70

[Yhn]

Hello everyone! I see it's "VERIFIED FIXED". But where's the option? What should I type in the about:config window?

Comment 71

[Tony Mechelynck [:tonymec]]

(In reply to Yhn from comment #70)
> Hello everyone! I see it's "VERIFIED FIXED". But where's the option? What
> should I type in the about:config window?

The new preference is defined at new line 313 in the patch.

Comment 72

[Yhn]

(In reply to Tony Mechelynck [:tonymec] from comment #71)
> (In reply to Yhn from comment #70)
> > Hello everyone! I see it's "VERIFIED FIXED". But where's the option? What
> > should I type in the about:config window?
> 
> The new preference is defined at new line 313 in the patch.

Get it, yet I'd rather say it's "browser.tabs.closeWindowWithLastTab".

Comment 73

[Tony Mechelynck [:tonymec]]

(In reply to Yhn from comment #72)
> (In reply to Tony Mechelynck [:tonymec] from comment #71)
> > (In reply to Yhn from comment #70)
> > > Hello everyone! I see it's "VERIFIED FIXED". But where's the option? What
> > > should I type in the about:config window?
> > 
> > The new preference is defined at new line 313 in the patch.
> 
> Get it, yet I'd rather say it's "browser.tabs.closeWindowWithLastTab".

Know the saying? «Give me a fish, I'll eat for a day. Teach me how to fish, I'll eat all my life.» I was trying to show you how I had done my «fishing».

And sorry, guys, for the bugspam.