Closed Bug 236721 Opened 17 years ago Closed 15 years ago

ctrl-w on last tab closes firefox

Categories

(Firefox :: Tabbed Browser, defect, P3)

2.0 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 2 beta1

People

(Reporter: mark, Assigned: zeniko)

References

Details

(Keywords: fixed1.8.1, Whiteboard: SWAG: 1d)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

I'm not sure if this is a bug, but when you do ctrl+W on the last tab firefox
closes, while the close-tab button closes the tab bar.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
This is probably related to bug 156082.

Confirming with Mozilla 1.7a and Firefox 0.8 under WinXP.

If you have the tabbar always visible and there is only 1 tab, pressing the X
closes tab but not the window. Ctrl+w closes the entire window even though the
File menu states that Ctrl+w means close tab and not close window. Ctrl+w should
behave just like pressing the X or the File menu should be changed to say that
Ctrl+w means close window.
Status: UNCONFIRMED → NEW
Component: Browser-General → Tabbed Browser
Ever confirmed: true
There is already a Mozilla bug on this.
Assignee: general → firefox
Component: Tabbed Browser → General
Product: Browser → Firefox
Version: Trunk → unspecified
there's a Firefox bug on this too
QA Contact: general → mconnor
Whiteboard: DUPEME
Sounds similar to bug 233539, but that one says Firefox SHOULD close when
closing the last tab.
Assignee: firefox → mconnor
In RC1, Firefox doesn't hide the tab bar but goes to about:blank.
This still happens on FireFox 1.0 final (at least the linux version)...
And in Windows... 
I agree.  FF should close when the last tab closes instead of changing to a
blank page.
You realize you just commented in favour of preserving the status quo, yet voted
for "fixing" this.

Ctrl-W is Close Document in GNOME and a number of Windows apps.  Since the other
current methods of closing a tab just clear it, we should be consistent.

There's also the matter that Apple's HIG expects an inversion of the current
shortcuts (Cmd-W closes window, Cmd-Shift-W closes document (in this case the
browser tab)).
Whiteboard: DUPEME
Ok, I wasn't aware of Apple's HIG. Anyway, IMHO it feels odd that clicking the
"close tab button" when there's only one tab opened _doesn't_ close FFox
_window_, while pressing CTRL+W (which is associated to "close tab" action)
does. Also, there's a separate shortcut associated to the close window action
(SHIFT+CTRL+W), so I believe CTRL+W and SHIFT+CTRL+W should indeed have
different purposes, and that CTRL+W should not close the whole window.
See also Firefox Bug 263003 (Inconsistent behavior for "Hide Tab bar when only
one website is open"=FALSE), which I filed after Bug 248987 (When closing last
tab the tab bar disappears indefinitely until new tab is opened) was fixed
incompletely.  
*** Bug 263003 has been marked as a duplicate of this bug. ***
*** Bug 273654 has been marked as a duplicate of this bug. ***
This is a dupe of bug 206142.
not really, we've since changed a number of things with how other close tab
methods work, so this remains as an inconsistency.  The conclusions of that bug
were wrong, but real HIG-based arguments weren't presented.

Duping this to that and reopening doesn't serve much of a purpose.
A small change that I use on my Firefox 1.0 installation to achieve this
behaviour is as follows:

From browser.jar, unzip and edit chrome\browser\content\browser\browser.js 
~line 1372:

==========================================================
function BrowserCloseTabOrWindow()
{
  if (gBrowser.localName == 'tabbrowser' &&
gBrowser.tabContainer.childNodes.length > 1) {
    // Just close up a tab.
    gBrowser.removeCurrentTab();
    return;
  }
+  if (gBrowser.localName == 'tabbrowser' &&
gBrowser.mTabContainer.childNodes.length == 1) {
+    // If this is the last tab, open "about:blank" tab, and don't close the window
+    loadURI('about:blank', null);  // still leaves back & forward buttons
active though
+    return;
+  }

  BrowserCloseWindow();
}
==========================================================


Note that this change in its current form has a problem though in that it leaves
the back and forward buttons active (i.e. the user can press back, and get the
previous page). [An alternative is to go "gBrowser.addTab('about:blank');" and
then "gBrowser.removeCurrentTab();", which
opens a new tab and then closes the current one, but this causes an ugly brief
flashing effect as the new tab is added and the current one removed.]
Can't you simply get Ctrl+W and "Close Tab" call the same function?
Sounds good to me - no idea what other function is being called though! I only
found the above function by digging through browser.xul, and I didn't find
browser.xul particularly revealing about what function the "close tab" button is
calling. Anyone know?
After a bit of poking around, it looks like the close tab button is just calling
removeCurrentTab() - See tabbrowser.xml, around line 93, which reads:
  onclosetab="var node = this.parentNode;
              while (node.localName != 'tabbrowser')
                 node = node.parentNode;
              node.removeCurrentTab();">

So the easiest answer may be to add a function that just does this, to
browser.js, around line 1389:
+function BrowserCloseTab() 
+{
+	gBrowser.removeCurrentTab();
+}
+

And change Ctrl-W and File->Close Tab to use this new function, in browser.xul,
around line 99:
    <command id="cmd_print" oncommand="PrintUtils.print();"/>
-    <command id="cmd_close" oncommand="BrowserCloseTabOrWindow()"/>
+    <command id="cmd_close" oncommand="BrowserCloseTab()"/>
    <command id="cmd_closeWindow" oncommand="BrowserTryToCloseWindow()"/>

And then there no longer seems to be anything calling BrowserCloseTabOrWindow(),
so this can probably be removed from browser.js, around line 1372:
-function BrowserCloseTabOrWindow()
-{
-  if (gBrowser.localName == 'tabbrowser' &&
gBrowser.tabContainer.childNodes.length > 1) {
-    // Just close up a tab.
-    gBrowser.removeCurrentTab();
-    return;
-  }
-
-  BrowserCloseWindow();
-}
-

The changes above mean that the special-case handling of tab closing (for when
there is only one tab left) is then handled by the current removeTab()
implementation, in tabbrowser.xml, around line 1045. This current implementation
appears to have two problems though:
1) If autohiding of the tab bar is turned ON, then ctrl-W does nothing (i.e. it
keeps the last tab open at the current page, and does not change it to about:blank).
2) If autohiding of the tab bar is turned OFF, then ctrl-W does change the last
page to be about:blank, but it keeps the history (i.e. the back button still works).

Both these are probably bad things, but they seem to be pre-existing problems
with the current implementation of removeTab(), which the above changes just
expose, rather than create.

To fix the first of these problems in removeTab(), suggest the following minor
reordering changes to tabbrowser.xml, around line 1053:
            var l = this.mTabContainer.childNodes.length;
            if (l == 1) {
-              if (!this.mPrefs.getBoolPref("browser.tabs.autoHide")) {
+              if (this.mPrefs.getBoolPref("browser.tabs.autoHide")) {
+                 // hide the tab bar
+                 this.mPrefs.setBoolPref("browser.tabs.forceHide", true);
+                 this.setStripVisibilityTo(false);
-                // blank the tab
-                this.loadURI("about:blank");
-                return;
              }
-             // hide the tab bar
-             this.mPrefs.setBoolPref("browser.tabs.forceHide", true);
-             this.setStripVisibilityTo(false);
+             // blank the tab
+             this.loadURI("about:blank");
              return;
            }

I'm not sure how to fix the second of these (clearing the back button). Do we
even want to do this? Maybe this isn't such a bad thing, but it is a bit
inconsistent (only the last tab keeps its back button, whereas all the other
tabs are destroyed completely, including their back button histories).

Over to you folks for comments / thoughts / proper patch creation / etc.
Here's an update that fixes the one remaining problem noted in the above comment
- i.e. it blanks the back and forward buttons when there's only one tab left
(same as changes above, but adds the 'sessionHistory' lines in tabbrowser.xml, ~
line 1067, to clear the back/forward buttons):

            var l = this.mTabContainer.childNodes.length;
            if (l == 1) {
              if (this.mPrefs.getBoolPref("browser.tabs.autoHide")) {
              	// hide the tab bar
              	this.mPrefs.setBoolPref("browser.tabs.forceHide", true);
              	this.setStripVisibilityTo(false);
              }
              
              // blank the tab
              this.loadURI("about:blank");
              
              // clear the tab's back and forward buttons.
              var purge = this.sessionHistory.count;
              this.sessionHistory.PurgeHistory(purge);
              
              return;
            }

Also, I've been running with the updates listed in the previous comment since
the beginning of this month, and they seem to work fine. However, creating a
suitable proper patch for attachment is beyond me, so if anyone is up to that
then please don't be shy!
*** Bug 283948 has been marked as a duplicate of this bug. ***
The bug, which previously had been fixed, appeas to have come back in FF 1.0.1:
CTRL+W on last tab closes the browser instead of the tab, leaving a blank tab in
its place. This is irrespective of whether or not one has "hide the tab bar when
only web site is open" pref selected.
ctrl+w closes tab (if more than 1) but closes the whole app when closing the
unique tab (there's only 1 tab in the window).

Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.7.8) Gecko/20050511
Firefox/1.0.4
(In reply to comment #21)
> Here's an update that fixes the one remaining problem noted in the above comment
> - i.e. it blanks the back and forward buttons when there's only one tab left
Cross-ref bug 281012 comment 5
This is actually a very interesting bug here.

So does anyone agree that Ctrl+W and Ctrl+Shift+W needs to stick to just one
operation each?

mconnor states that Ctrl+W is to close document, and it seems to me each tab is
treated as a separate document, so Ctrl+W should always be closing a tab, and
never the window unless called whenever no tabs are currently present. Is that
correct?
I have a fix for here...ctrl+w still closes tabs, but when only one tab is left,
ctrl+w will blank that tab, just like Close Tab does from the tab context menu
(also cleans up history for security, as in comment 20). Still haven't made
anything yet to screw with the File menu for this, so that Close takes the place
of Close Tab when the only tab left is blanked.

If this is the right approach, let me know so I can finalize the patch.
> If this is the right approach, let me know so I can finalize the patch.

Yes, I agree that Ctrl+W and Ctrl+Shift+W need to stick to just one
operation each, and yes, that sounds like the right approach to me. If anyone
has any objections to this approach, or objects to having consistent behaviour
for Ctrl+W and Ctrl+Shift+W, then please say so now.

> Still haven't made
> anything yet to screw with the File menu for this, so that Close takes the place
> of Close Tab when the only tab left is blanked.

On my Firefox install (I'm still running the original version 1.0), that's what
happens at the moment (i.e. File menu for Ctrl-W says "Close Tab", until there
is only one tab, and then it says "Close"). Did you maybe mean make it so that
that the File menu always says "Close Tab", even if there is only one tab left?
If so, below are some changes that do that, although the changes below are:
* Inefficient, in that it does the same thing repeatedly when doing it only once
will do.
* Buggy, in that it initially shows 'Close' in the File menu until a second tab
is opened, and then this changes permanently to 'Close Tab', irrespective of how
many tabs are open.

From chrome\toolkit\content\global\bindings\tabbrowser.xml :
      <method name="setStripVisibilityTo">
        <parameter name="aShow"/>
        <body>
        <![CDATA[
          this.mStrip.collapsed = !aShow;
-          if (aShow) {
-            // XXXdwh temporary unclean dependency on specific menu items in
navigator.xul
-            document.getElementById("menu_closeWindow").hidden = false;
-            document.getElementById("menu_close").setAttribute("label",
this.mStringBundle.getString("tabs.closeTab"));
-            if (!this.mTabbedMode)
-              this.enterTabbedMode();
-          }
-          else {
-            // XXXdwh temporary unclean dependency on specific menu items in
navigator.xul
-            document.getElementById("menu_closeWindow").hidden = true;
-            document.getElementById("menu_close").setAttribute("label",
this.mStringBundle.getString("tabs.close"));
-          }
+          if (aShow && !this.mTabbedMode) {
+              this.enterTabbedMode();
+          }
+          // XXXdwh temporary unclean dependency on specific menu items in
navigator.xul
+          document.getElementById("menu_closeWindow").hidden = false;
+          document.getElementById("menu_close").setAttribute("label",
this.mStringBundle.getString("tabs.closeTab"));
        ]]>
        </body>
      </method>


Also here is a small possible update to the help, from
chrome\help\locale\en-US\help\menu_reference.xhtml :
  <h3 id="close_tab">Close Tab</h3>
-  <p>Closes the current tab and selects the rightmost tab. This menu item is
-    visible only if more than one browser tab is currently open.</p>
+  <p>Closes the current tab and selects the rightmost tab. If only one browser
+    tab is currently open, then this will keep one blank tab open.</p>
(In reply to comment #28)
> > If this is the right approach, let me know so I can finalize the patch.
> 
> Yes, I agree that Ctrl+W and Ctrl+Shift+W need to stick to just one
> operation each, and yes, that sounds like the right approach to me. If anyone
> has any objections to this approach, or objects to having consistent behaviour
> for Ctrl+W and Ctrl+Shift+W, then please say so now.

100% agreed, this sounds like the right approach to me, too.

Best,

Andre
Let me make sure I'm clear here.

Ctrl+W will close down a tab completely, until only one tab is left. When that
tab is left, ctrl+w will blank the tab and clear session history (basically a
quicker way of closing the tab and creating a new one). If ctrl+w is hit again,
the window is then closed.

This is what occurs in my patch for this, and makes sense to me.

Wanna make sure this is clear, that no one is thinking ctrl+w should never close
a window, as I think ctrl+w should close the whole window if there are no active
tabs, since from my understanding, the window becomes the document.
Personally I'm very keen for ctrl+w to never close the window, and I imagine the
person who submitted this bug feels the same way.

However, I can always use an extension to make it that way: TabMix does it. I'd
like an option as to whether ctrl+w closes the window, and I'd like shift+ctrl+w
to simply close the current window, regardless of number of tabs open. My
preferred behaviour for ctrl+w: close current tab; when only one tab, blank the
current tab and delete the tab's history; when on a blank tab, do nothing.

I'm not sure about other people's attitudes though, but I know that a lot of
people do want the behaviour I've described above.
(In reply to comment #30)
> Let me make sure I'm clear here.
> 
> Ctrl+W will close down a tab completely, until only one tab is left. When that
> tab is left, ctrl+w will blank the tab and clear session history (basically a
> quicker way of closing the tab and creating a new one). If ctrl+w is hit again,
> the window is then closed.
> 
> This is what occurs in my patch for this, and makes sense to me.
> 
> Wanna make sure this is clear, that no one is thinking ctrl+w should never close
> a window, as I think ctrl+w should close the whole window if there are no active
> tabs, since from my understanding, the window becomes the document.

Mmmh... I beg to differ. IMHO the window does not become the document, it
_contains_ an empty document.

Take for example GEdit (GNOME text editor); CTRL+W affects only tabs, and when
the last one is closed, it becomes ineffective (it is even disabled on the File
menu), and the only way out of the application is through CTRL+Q. IMHO that's
the right behavior.
> Ctrl+W will close down a tab completely, until only one tab is left.

Yes.

> When that
> tab is left, ctrl+w will blank the tab and clear session history (basically a
> quicker way of closing the tab and creating a new one).

Yes.

> If ctrl+w is hit again,
> the window is then closed.

No. If Ctrl+W is pressed again, treat as above - i.e. you still have the window
open, with one blank tab, with no session history.

Personally, I want Ctrl+W to never ever close the window. I don't want to press
Ctrl+W and go "Whoa! Where did my browser window just go?" - which is what
happens currently. I would like one set of keypresses to close the window
(Ctrl+Shift+W, or Alt+F4), and another set of keypresses to close the current
tab and open a new blank one if only one remains (Ctrl+W). There should be no
intersection between these actions - I see closing the tab and closing the
window as being two very different things - one means "I'm done with the current
block of information, but this app is still useful to me", and the other means
"this entire app is no longer of any use to me" - they are conceptually
different things. The current approach flips between meaning each of these two
different things, and as a result the current behaviour is surprising and/or
annoying, because I have to have a ridiculously long stream of thought at the
moment, like this: "OK, how many tabs are open? Two. Okay, so ctrl-w will close
just this tab. Ok, so ctrl-w, closed it now. Now I want to close this one last
tab - but hang on, one tab is open, so this is trick, because I mustn't press
ctrl-W because with the current behaviour it will close the app as well, and I
don't want that. Ok, so I'm moving the mouse up to the tab bar, and I'm clicking
the X button, because there's no keypress to do this, and ok I've done that now,
and now I've just got one blank tab left open, which is what I actually want.
Now, I've forgotten, what was I doing before this?". Compare and contrast with:
"I'm done with these two tabs - press and hold ctrl-w - ok, they're gone". One
of these requires way too much thought, and the other is quick and easy. (The
phrase "Don't Make Me Think" championed by useability experts springs to mind.)
I never want to have to really think about or be surprised and/or annoyed by the
result of the keypress. I.e. one set of actions to close the tab, one set of
actions to close the window, no intersection = no surprises.
(In reply to comment #33)
In short, you want Ctrl+W to act like Ctrl+F4.
Has the code in comment 20 been formed into a patch yet and made available
against the trunk/1.8 branch? I'd like to apply this and try it out.
Flags: blocking-aviary2.0?
I don't want this changed, unless some other key is added that has the
functionality that ctrl-W used to have.  I don't mind if ctrl-f4 and ctrl-w are
swapped in function.  For me it is necessary to have a single keystroke (I
program it as one of my mouse buttons) that can close a tab or a window if it
only has one tab.  Why?  Because I open several tabs, but then will open a new
window with several tabs when there are too many tabs to see their titles.  As I
finish reading and close stuff, I would end up with a lot of empty windows to
close if my mouse button didn't close the windows as well.
(In reply to comment #37)
> I don't want this changed, unless some other key is added that has the
> functionality that ctrl-W used to have.

Does it have to be *the same* key? If you just want a key combination to close
the window, ctrl-shift-w does that, so you never have to use the mouse! If
that's all you want, then you've already got it!

I do think the best thing is to have the choice, but I know that proliferation
of options isn't popular...
(In reply to comment #17)
> A small change that I use on my Firefox 1.0 installation to achieve this
> behaviour is as follows:
> 
> From browser.jar, unzip and edit chrome\browser\content\browser\browser.js 
> ~line 1372:
> 
> ==========================================================
> function BrowserCloseTabOrWindow()
> {
>   if (gBrowser.localName == 'tabbrowser' &&
> gBrowser.tabContainer.childNodes.length > 1) {
>     // Just close up a tab.
>     gBrowser.removeCurrentTab();
>     return;
>   }
> +  if (gBrowser.localName == 'tabbrowser' &&
> gBrowser.mTabContainer.childNodes.length == 1) {
> +    // If this is the last tab, open "about:blank" tab, and don't close the
window
> +    loadURI('about:blank', null);  // still leaves back & forward buttons
> active though
> +    return;
> +  }
> 
>   BrowserCloseWindow();
> }
> ==========================================================

The small change I use is just to delete BrowserCloseWindow(), then Ctrl+W
closes any tab until just one is shown ie the default one. Ctrl+W then does
nothing but Ctrl+F4 still closes the window which is what I expect to happen.

Discussion here http://forums.mozillazine.org/viewtopic.php?t=310696
(In reply to comment #38)
> (In reply to comment #37)
> > I don't want this changed, unless some other key is added that has the
> > functionality that ctrl-W used to have.
> 
> Does it have to be *the same* key? If you just want a key combination to close
> the window, ctrl-shift-w does that, so you never have to use the mouse! If
> that's all you want, then you've already got it!
> 

Yes, it has to be a single key, I explained why.  I have one button on the mouse
to spare, which corresponds to one keystroke.  For possible keys there are
ctrl-W, ctrl-shift-W, ctrl-f4- as long as any one of those works similar to how
ctrl-W used to work- can close one tab and can also close the window, that's
fine.  I can't use two mouse buttons both for the purpose of closing
tab/windows.  Even if ctrl-shift-f4 worked like the old ctrl-W that would be ok
(if ctrl-shift-F keys are able to be used).

Also, some talk in comments would allow ctrl-w to close tabs, would blank the
last tab if it had content, and would only close the window if the tab was
already blank.  That solution is also ok with me, it would mean pressing ctrl-w
twice to close the last tab and window but that is ok.
On the other hand, if ctrl-W closes tabs but can never close a window, and no
other key can close tabs and windows, I don't like that.
Following already long forum discussion on this bug, and to make it short and
summarize:

      Ctrl+w => close current tab, but  >> NEVER completely close Firefox  <<
      Ctrl+Shift+w => close current window;

The only open exception for Ctrl+w could be:
in case mutiple windows are open, should Ctrl+w on last tab of extra windows
close these extra windows.

Comment:
For information Ctrl+w in opera never close any window.
Reminder: firefox help instructions / Keyboard shortkeys say that Ctrl+w only
close tab.
(In reply to comment #41)
> The only open exception for Ctrl+w could be:
> in case mutiple windows are open, should Ctrl+w on last tab of extra windows
> close these extra windows.

Having ctrl-w act differently on either the "one document on a single remaining
tab in a window" or "one document directly within a window" case depending on
whether other application windows are open seems quite unpredictable as a
practical user experience.

Generally, my feeling is that the current trend is to lose the application in
favor of winning the document as a first class user interface object.

The gnome guidelines indicate ctrl-w closes a document [1]; as such, I'd argue
that the _status quo_ in the _default configuration_ where no tab bar is visible
when a single document inhabits a window, _behaves exactly as it should_; ctrl-w
always closes a document along with its representative immediate visible
container. From that perspective, the labeling of the menu item corresponding to
ctrl-w could use adjustment, and perhaps the behavior of a visible single-item
tab bar behavior (non-default configuration) could bear tweaking to match e.g.
gedit (open blank document on closing last document and its representative
immediate container).

[1] http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#id2554412
> In short, you want Ctrl+w to act like Ctrl+F4.

Yes. Ctrl+w should behave as the tab bar's close button already does, and as
Ctrl+F4 already does, and as right click on tab -> "Close tab" already does.
Ctrl+w and File->Close Tab should be consistent with every other tab-closing
method, and close the tab but not the window.

> The small change I use is just to delete BrowserCloseWindow()

Yep, that's a quick way of getting similar behaviour until this is resolved (the
only thing is as you say it won't close/blank the tab if there is only one tab
left).

> Ctrl+F4 still closes the window which is what I expect to happen

On a fresh download of Firefox 1.5 beta 1, Ctrl+F4 does not close the window (or
at least it doesn't for me).

> For information Ctrl+w in opera never close any window.

Same in NetCaptor. There's plenty of multi-tabbed browser precedent for having
Ctrl+w never close a window.

> Having Ctrl+w act differently [ ... ] depending on
> whether other application windows are open seems quite
> unpredictable as a practical user experience.

Agreed; Ctrl+w should be consistent irrespective of how many browser windows are
open.

> The gnome guidelines indicate Ctrl+w closes a document [1];

Agreed too; But also notice that Ctrl+q means quit, and is a different key from
Ctrl+w. Moreover, note that Ctrl+w says "Close the current document" - it does
not say "Close the current document, and quit the application if there are no
documents left open".

With the patch, Ctrl+w does close the document/tab, but it opens a blank
document/tab if it's the last one (which I think maybe is what you're saying
gedit does). Ctrl+Shift+w will still close the current window.
> > The gnome guidelines indicate Ctrl+w closes a document [1];
> 
> Agreed too; But also notice that Ctrl+q means quit, and is a different key from
> Ctrl+w. Moreover, note that Ctrl+w says "Close the current document" - it does
> not say "Close the current document, and quit the application if there are no
> documents left open".

Indeed; however, I don't think "the application" or "the process" is so
meaningful a concept here that document related keybindings' behavior should
need to avoid incidentally ending it by the closing of the last document and its
representative immediate container, if it is a window.
This bug has been biting me for a long time now in the 1.5 branch builds - is there no chance at all that this could be fixed before 1.5?
I still think that my quick hack is the simplest way to solve this for the time being...
See comment #39
Detailed instructions: http://forums.mozillazine.org/viewtopic.php?p=1730464#1730464
If this is to be changed, please fix it as described in comment 30- closing the last tab with ctrl-w only blanks the tab and does not close the browser, but closing the last blank tab closes the application.  If someone is trying to close the last already blank tab, I think they want the browser closed.  I like to open lots of tabs, and close them one by one and close the app when the last is closed.  If that takes an extra keystroke, blanking the window and then closing the app, that is ok.  But since when you open lots of tabs, they move off the screen to the right and do not make a 2nd row, you have to open a new window if you want more tabs that you can access and see how many there are.  When you open new windows with lots of tabs, and then close the tabs, eventually you need to close the new windows.  If ctrl-w never closes the window, I am going to be mad.  Now, if the UI is changed so tabs form more than one row once when there are too many of them, then I could probably live with ctrl-w not closing a window.  But as it is, multiple browser windows are needed to have control over lots of tabs- and an easy way to close those extra windows is also needed.

Please!  If this has to be changed, try the comment 30 method first and see if that is enough to prevent people from accidentally closing the app!
> I like to open lots of tabs, and close them one by one and close
> the app when the last is closed.

Me too. I just want these two things to be different keystrokes, because closing a single tab and closing the browser are two fundamentally different things.

> If this has to be changed, try the comment 30 method first and see if
> that is enough to prevent people from accidentally closing the app!

I've tried it, and it's not enough. E.g. sometimes I realise that what I've been reading about isn't going to help me, and close all the 30 or so tabs I have open in 1 or 2 seconds by holding down ctrl-w. With the patch, the window stays open. Without, it kills the window, unless I'm super-super-super-fast with my reflexes to stop just in time for that last blank tab - but frankly this is one task where a humanoid lump of meat is no match for a 3 GHz and above CPU. 

If I wanted the whole window closed, then I would have just used ctrl-shift-w or Alt-F4. Playing "chicken", or "are you quicker than the CPU?" is not my idea of fun, or of a good UI.

> If that takes an extra keystroke, blanking the window and then
> closing the app, that is ok.

If you want to close the window, just use ctrl-shift-w. (I.e. same keypress as usual + shift key). That's your one extra keystroke for closing the app.

> Now, if the UI is changed so tabs form more than
> one row once when there are too many of them, then I could probably live with
> ctrl-w not closing a window.

That's exactly the UI that I've been using for the past year (i.e. only one window, with multiple rows of tabs, no tabs are hidden, and ctrl-w doesn't close the window), and honestly I find it works very well.

The extensions that allow you to do multi-tab-rows are either FlowTabs or TabMixPlus, and the bug for adding multi-tab rows natively (or some other mechanism) is bug 155325.

Once you're using that UI, then ctrl-w ever closing the browser becomes especially annoying. If you don't believe me, try it out for yourself (by installing one of the extensions, and applying this bug's patch to your install using just zip/unzip and a text editor). I've tried your approach, so before you knock it, it's only fair that you try this.
(In reply to comment #48)

I like the flowtabs extension, but until it is the default I cannot support changing ctrl-W.
You would say that I should install an extension to get behavior that I like; I could say the same for you, that an extension could change the Ctrl-W behavior to please you.  The real question is what gives a wide variety of users good results without extensions.  I think that your example of holding down the Ctrl-W key to close all tabs and start with a blank window is unusual usage, but I do agree that having an easy way to close all tabs and start with a blank window would be nice.
On the other hand, as long as multiple browser windows are common (among advanced users they are common when many tabs and no flowtabs extension are used, and among novice users they are very often common because users don't understand tabs) an easy way to treat all the windows and their tabs in the same way and close the new windows is needed.  
Until flowtabs behavior is the default, I think changing the ctrl-w function will make trouble for many (and jumping back and forth from ctrl-w to ctrl-shift-w when dealing with many browser windows is not a good solution, it slows things down and also as comment 40 describes it is not good for users with programmable mouse buttons or programmable keys/keypads for closing things).
You don't seem to be willing to use the ctrl-f4 key for your tab closing (because it already does behave the way you want it to), I can understand that, it can be a bit harder to reach.  But I am willing to use the ctrl-f4 instead- if ctrl-W must be sacrificed for the people who use your key-repeat technique, changing ctrl-f4 to take its place should accommodate most people.  But, those arguing for consistency don't want that.

If there has to be consistency, then the change that would harm the fewest people would be that in comment 30.  The only situation where it seems people would be likely to accidentally close a window would be the key repeat case that you describe, which I do not believe is normal behavior.  I would argue that a new key combination that closes all tabs and opens a blank one would be a more appropriate way to do that task.
Comment on attachment 195101 [details] [diff] [review]
Patches as per comment 20 and comment 21, updated for a nightly build.

This is a patch for Seamonkey, and should be part of a Seamonkey bug.
Attachment #195101 - Flags: review?
OS: Windows XP → All
Status: NEW → ASSIGNED
Flags: blocking-aviary2? → blocking-aviary2+
I don't know that this is a good idea. Can someone explore all the use-cases, the effects before and after, the pros and the cons etc on the Mozilla Wiki somewhere? 
IE7 actually exhibits this behavior and it is stupendously annoying. Also completely out of the question on OS X. 
This feels to me like it could develop into one of those religious arguments, and although I have a pretty strong feeling about my opinion, I don't know that other people's practices are any *better*.

The way I see it, a proper tabbed browser should involve one or multiple windows in which one has one or multiple tabs. Closing tabs in a particular window is like closing windows on your computer: when you have finished with the last current window you don't necessarily want to turn off the computer.
I might want multiple windows because they contain different kinds of sites in them; so I don't want to enable single-window mode. But I do only want to close the window when I specifically ask to.
By virtue of Firefox being a tabbed browser, tabs have become like windows, and the window has become something different: the "container", basically. As Nick suggests above, closing a tab and closing a window are therefore different *types* of operations in the way *we* use a tabbed browser, and as such changing the behavious of ctrl-w just because there's only one tab open doesn't make sense to us.

But yeah, I can use an extension like Tab Mix Plus to induce the kind of behaviour I think is "natural" for ctrl-w. Whether this behaviour should be the default depends on what tabbed-browsing paradigm Firefox wants to promote, effectively, and it may be that now that the current behaviour is how it's been for some time, changing it would be inadvisable (even though it'd be my preference).
I am not necessarily against this, I was just stating my high levels of suspicion. This needs a lot of thought and research. I'd like to see some serious considered discussion and breakdown in the wiki. 
> Can someone explore all the use-cases,
> the effects before and after, the pros and the cons
> etc on the Mozilla Wiki somewhere? 

Okay. There's now a page giving the use cases, and my understanding of the pros & cons at:
http://wiki.mozilla.org/Ctrl_W_not_close_app
(In reply to comment #55)
> > Can someone explore all the use-cases,
> > the effects before and after, the pros and the cons
> > etc on the Mozilla Wiki somewhere? 
> 
> Okay. There's now a page giving the use cases, and my understanding of the pros
> & cons at:
> http://wiki.mozilla.org/Ctrl_W_not_close_app
> 

Well done, I guess all arguments are present in a concise manner. Nice work.
(In reply to comment #55)
> > Can someone explore all the use-cases,
> > the effects before and after, the pros and the cons
> > etc on the Mozilla Wiki somewhere? 
> 
> Okay. There's now a page giving the use cases, and my understanding of the pros
> & cons at:
> http://wiki.mozilla.org/Ctrl_W_not_close_app
> 

Good job on getting that written up, but you missed off a major (IMO) point. If a window was opened using script, then it can close itself using script. Therefore if your last tab is on which was opened using script, then it could close itself at any time, which would unexpectedly close the whole window. This is infact how I discovered this bug (see dupe bug 283948).
Priority: -- → P4
Target Milestone: --- → Firefox 2 alpha2
Component: General → Tabbed Browser
Priority: P4 → P3
Hardware: PC → All
Whiteboard: SWAG: 1d
Blocks: 281012
As proposed at the wiki, this patch implements the compromise alternative to close  the window only if the tab bar is hidden when only one tab is visible. Like this you can choose whether you prefer Firefox to be rather MDI or rather SDI and it will behave accordingly (fixing bug 156082 should further improve the MDI aspect).

This would also be consistent with what you can read aside "Ctrl+W" in the File menu (being "Close" with one tab and no tab bar and "Close Tab" otherwise).
Attachment #217610 - Flags: review?(mconnor)
Comment on attachment 195101 [details] [diff] [review]
Patches as per comment 20 and comment 21, updated for a nightly build.

Marking old patch as obsolete.

New patch looks good: one line patch, that keeps the folks who use multiple windows and not tabs happy, and makes the folks who use multiple tabs and want long-lived windows happy. Thumbs up from me.
Attachment #195101 - Attachment is obsolete: true
Thanks Simon, thanks Nick!
As someone who's advocated on this thread before (but not very productively coding-wise, sorry!) I'll add that I'm one who, like Nick, wants CTRL-W to always close the tab only, and I'm one who always leaves the tab bar there, so this patch is just the ticket. All good :)
Comment on attachment 217610 [details] [diff] [review]
close tab or window depending on tab bar visibility

this will go in today
Attachment #217610 - Flags: review?(mconnor)
Attachment #217610 - Flags: review+
Attachment #217610 - Flags: approval-branch-1.8.1+
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1
Whiteboard: SWAG: 1d → SWAG: 1d [checkin needed (1.8 branch)]
Checked in on the 1.8 branch.
mozilla/browser/base/content/browser.js 	1.479.2.143

Is this bug fixed now?
Whiteboard: SWAG: 1d [checkin needed (1.8 branch)] → SWAG: 1d
Version: unspecified → 2.0 Branch
Not unless this or a similar patch is also applied to the trunk.
Oh, I hadn't realized this wasn't checked in on the trunk.
Assignee: mconnor → zeniko
Status: ASSIGNED → NEW
Keywords: fixed1.8.1
QA Contact: mconnor → tabbed.browser
mozilla/browser/base/content/browser.js 	1.636
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Depends on: 341067
Depends on: 341097
Depends on: 352785
see bug 357724 for a significant new problem with this behaviour.
This regressed with bug 392870. Filed bug 455852.
Bug 455852 was morphed, so I filed bug 456405.
Firefox 13.0.1

CTRL+W on last tab quits Firefox, despite the fact that the 'Close tab' option (or red X) is not available.
Hello,

What do other browsers do when doing Ctrl+W (or clicking the [x]) of last tab?

I know that Opera 50+ blanks the last tab and does not close the application and that's by default.

Chrome (or Chromium) closes the application: that's by default. But there are tab manager extensions that will blank the last tab, just like Opera.

I do not know about Safari 11.3 (or better): can anyone report this?

I do not know about MS-Edge 17 (or better): can anyone report this?
You need to log in before you can comment on or make changes to this bug.