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

VERIFIED FIXED in Firefox 3.1b1

Status

()

Firefox
Tabbed Browser
--
major
VERIFIED FIXED
10 years ago
5 years ago

People

(Reporter: Daniel Cater, Assigned: dao)

Tracking

(Blocks: 1 bug, {ue})

Trunk
Firefox 3.1b1
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

10 years ago
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.

Updated

10 years ago
Flags: wanted-firefox3.1?
OS: Linux → All
Version: unspecified → Trunk
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.
(Assignee)

Updated

10 years ago
Assignee: nobody → dao
Status: NEW → ASSIGNED
Keywords: regression
Hardware: PC → All
Summary: Closing last tab closes window instead of blanking it → Add a hidden pref for not closing the window with the last tab
as addition to Dão's non-comprehensible bug morphing step: this shouldn't be moved to hidden pref land either :-/

Comment 3

10 years ago
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.
(Assignee)

Updated

10 years ago
Blocks: 425375
(Reporter)

Comment 4

10 years ago
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

10 years ago
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
(Assignee)

Comment 6

10 years ago
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

10 years ago
(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

10 years ago
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.

Updated

10 years ago
Keywords: ue

Comment 9

10 years ago
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

10 years ago
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

10 years ago
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".
(Assignee)

Comment 12

10 years ago
(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

10 years ago
(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

10 years ago
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.
(Assignee)

Comment 15

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
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
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.
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

10 years ago
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

10 years ago
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

10 years ago
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.
Severity: normal → major
Flags: blocking-firefox3.1?
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

10 years ago
(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?
(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.
Created attachment 339755 [details]
patch as an extension

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

Comment 30

10 years ago
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.
Attachment #339754 - Flags: review?(dao) → review-
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

10 years ago
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.
(Assignee)

Comment 33

10 years ago
(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.
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.
(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.
(Assignee)

Comment 36

10 years ago
Created attachment 339768 [details] [diff] [review]
patch

Using BrowserOpenTab fixes bug 425375.
"return null" was a copy&paste mistake -- _endRemoveTab doesn't have return value.
Attachment #339754 - Attachment is obsolete: true
Attachment #339768 - Flags: review?(gavin.sharp)
Attachment #339768 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 37

10 years ago
http://hg.mozilla.org/mozilla-central/rev/dcb55e794dd5
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b1

Comment 38

10 years ago
> 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.
(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.
Target Milestone: Firefox 3.1b1 → ---
(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.
(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.
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.
(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.
(Reporter)

Comment 44

10 years ago
(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.
(Reporter)

Comment 45

10 years ago
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.
Created attachment 339871 [details] [diff] [review]
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.
Attachment #339871 - Flags: review?(gavin.sharp)
(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.
(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.
(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.
Attachment #339871 - Attachment is obsolete: true
Attachment #339871 - Flags: review?(gavin.sharp)
Comment on attachment 339871 [details] [diff] [review]
patch

This looks like a patch for bug 456382 (which already has a patch).
Depends on: 456382
(Assignee)

Updated

10 years ago
No longer depends on: 456382
Depends on: 456425
(Assignee)

Updated

10 years ago
No longer depends on: 456425
Ok, this bug depends on bug 456382 then.
(Assignee)

Updated

10 years ago
Blocks: 456405
(Assignee)

Updated

10 years ago
Target Milestone: --- → Firefox 3.1b1

Comment 52

10 years ago
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++;
     }
(Assignee)

Comment 53

10 years ago
(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?
(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

10 years ago
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.
(Assignee)

Comment 56

10 years ago
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

10 years ago
Please don't forget about bug 456405 as well.

Comment 58

10 years ago
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

10 years ago
(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
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.
Status: RESOLVED → VERIFIED
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?
Blocks: 477832

Comment 61

10 years ago
(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.
(Assignee)

Comment 62

10 years ago
Test checked in:
http://hg.mozilla.org/mozilla-central/rev/bd315a993149
Flags: in-testsuite+

Updated

9 years ago
Duplicate of this bug: 501410

Updated

9 years ago
Duplicate of this bug: 501417

Comment 65

9 years ago
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.
The hidden pref works for me in 3.5.

Updated

9 years ago
Duplicate of this bug: 499170

Comment 68

9 years ago
(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

Updated

9 years ago
Duplicate of this bug: 501620

Comment 70

6 years ago
Hello everyone! I see it's "VERIFIED FIXED". But where's the option? What should I type in the about:config window?
(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

6 years ago
(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".
(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.
You need to log in before you can comment on or make changes to this bug.