156082 - Don't hide the tab bar when clicking the close box (pref for showing single tab ["Hide tab bar when only one tab is open"] is ignored)

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P5)

Description

[Jeremy M. Dolan]

Don't hide the tab bar when clicking the close box

Bug 150099's 'fix' makes absolutely no sense and is "fundamentally
counterintuitive, producing results that cannot" possibly "be predicted or
expected by the user"

See bug 150099 comment 28

Comment 1

[Jeremy M. Dolan]

Nominating for the same things the original bug had. CC'ing mpt (sorry chap),
but maybe he can properly explain why this just can't be, if it isn't obvious
enough.

Comment 2

[jag (Peter Annema)]

-> UI design, cc'ing Lori.

Comment 3

[Mike Kaply [:mkaply]]

Man this was a bad idea.

So I click close on my tab browser and the only way to get it back is to open a
new tab and then close that tab?

Bad idea.

The close button shouldn't even be there if I have the browser set to always
display the tab bar, or at LEAST if I click close when I have that pref set, it
should change the pref so that when I go back into preferences, I can turn it
back on.

As it is, I have no tab bar and the pref says I should. Figure that out.

Comment 4

[jag (Peter Annema)]

Use View -> Show/Hide -> Tab Bar to show the tab bar again.

The pref is about auto-hiding, the close box forcibly hides the tab bar when the
auto-hide pref is off. I tried not to reuse the pref, because if you do, there's
another case where you'll get confusion, which is when you've used the close box
to hide the tab bar, open a second tab and then later close that second tab, the
tab bar will automatically hide (not what's expected), leaving you with no easy
way to get the tab bar to stay visible (other than going back to the prefs).

The problem here is that there are two models to hide the tab bar, one that
hides it automatically when there's one tab left, another where the user hides
it, and their overlap confuses people who've previously only been exposed to the
auto-hide feature.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 159191 has been marked as a duplicate of this bug. ***

Comment 6

[Torben]

*** Bug 182000 has been marked as a duplicate of this bug. ***

Comment 7

[Torben]

*** Bug 183475 has been marked as a duplicate of this bug. ***

Comment 8

[Torben]

*** Bug 183473 has been marked as a duplicate of this bug. ***

Comment 9

[Torben]

*** Bug 183422 has been marked as a duplicate of this bug. ***

Comment 10

[guanxi]

jag: "The problem here is that there are two models to hide the tab bar ... and
their overlap confuses people who've previously only been exposed to the
auto-hide feature."


The problem is that ordinary users lose the tab bar and never get it back.  I've
seen it on their Netscape 7 installs.

If they can't find the tab bar, then tabbed browsing effectively doesn't exist
in their browser.


"Use View -> Show/Hide -> Tab Bar"

I doubt many users will look until they find that command, two levels deep in a
menu, esp. when they don't necessarily know what this new feature does.  

Comment 11

[Michael Lefevre]

*** Bug 168421 has been marked as a duplicate of this bug. ***

Comment 12

[Michael Lefevre]

Bug 168421, which I just duped, points out that this bug occurs with ctrl+f4 as
well as a click on the close box.

Comment 13

[R.K.Aa.]

*** Bug 187871 has been marked as a duplicate of this bug. ***

Comment 14

[R.K.Aa.]

*** Bug 188267 has been marked as a duplicate of this bug. ***

Comment 15

[Geoff Filippi]

This is my observation of the issue:
[1.2.1 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130] 

When you click "x" on the tab bar with one tab open, the tab bar closes but the 
page stays up. After that, any browser windows that you open don't show the tab
bar. 

I made sure that "Hide the tab bar when only one tab is open" was DEselected in
preferences. Yet when only one tab is open, the tab bar is still hidden.

The bug, I guess, is that the preferences don't reflect the actual behavior in
this case.

A more intuitive behavior might be this:
When you click "x" with only one tab open, the tab you were viewing goes away,
and a new tab "(Untitled)" is opened. That is, the tab currently created by
File->New->Navigator Tab. This would seem more consistent to me because the
other toolbars are all hidden/shown through the View menu (and not by clicking
directly on them.) If you want to actually hide the tab bar, you should do so
with the view menu.

If this doesn't seem intuitive to everyone, then perhaps a preference could be
added: 
When only one tab is open:
"x" hides the tab bar OR
"x" closes the last tab and opens a new tab

Comment 16

[Jonadab the Unsightly One (Nathan Eady)]

> When only one tab is open:
> "x" hides the tab bar OR
> "x" closes the last tab and opens a new tab

"x" is not the right terminology to use.  First, there are other "x" buttons
all over the place, depending on your theme.  The stop button, for example.
Second, the close-tab buttom may not be an "x" at all, depending on theme.
Additionally, Ctrl-W does the same thing (or clover-W on Mac).  Also, what
happens if both of those are checked?  Shouldn't they be mutually exclusive?
Perhaps something more along these lines:

Attempting to close the last tab
  (*) replaces the page with a blank one
  ( ) hides the tab bar
  ( ) does nothing

(I marked about:blank as default because I listed it first, but it doesn't
actually matter what the default is; people who don't change prefs don't 
use tabs, either.)

I could also live with following the pref as it stands now and only hiding
the tab bar when "Hide the tab bar when only one tab is open" is checked,
or when the user hides it under Show/Hide in the View menu.  If we go that
way, the close-tab button should be disabled when only one tab is showing,
and Classic and Modern should be fixed to have it appear disabled ("greyed
out") when [disabled=true], just like other buttons (back, forward, &c).
(Whatever Modern and Classic both do, third-party themes eventually follow.)
This really would be what I would think would be right -- but the preference
approach above would be acceptable also, and lets us get away without adding
a disabled state to the button.

Comment 17

[mozilla]

This is a bug, the tab bar 'x' means close, nobody can dispute that.
Ctrl-w means close tab, nobody can dispute that.

They should do the same thing, simple as that.  If we started adding 'options'
for anything that didn't work as expected, the user would be swamped and give up!

If the user doesn't want the tab bar, they can use the existing options to do so.

C'mon, there are dozens of bugs reported on the same problem, why can't someone
spend 5min fixing the 'x' to ctrl-w?

You won't even accept the bug? won't even commit to a target milestone?  20+ppl
in the CC list can't be hallucinating.

Comment 18

[Simon Liddington]

This is definitely a bug. Here's some behaviour which to my mind proves it. With
the hide tab bar with one tab open pref not set, try opening a new window then
click the close tab. Tab bar disappears as we know. Now close your window and
open another new one ... hey where's the tab bar!!! This is a case of the pref
being blatantly ignored.

It's also a case of consistency. Why should the button suddenly do something
different just because there is only one tab left and more than that it does
something I thought I asked to never happen. The button should either not be
shown with one tab or close the tab leaving no tabs (like word) or leave a blank
tab. Any will do, but the current behaviour is wrong!

Comment 19

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 205626 has been marked as a duplicate of this bug. ***

Comment 20

[Jason Bassford]

Currently:

Window closes with: Ctrl-W, File -> Close Tab.
Tab bar hides with: Tab bar close (X).
Nothing (inactive): Context menu close. 

Right now, I would be much happier if everything did the same thing. 
Inconsistency sucks.  Even if every close method closed the tab bar (which I
*don't* think should be the case) I'd prefer things to what we have now.  Then,
at least, we could address every situation with one single patch.

Comment 21

[Rafael Ebron (:rebron)]

adt: nsbeta1-

Comment 22

[Jason Bassford]

*** Bug 222109 has been marked as a duplicate of this bug. ***

Comment 23

[guanxi]

*** Bug 220791 has been marked as a duplicate of this bug. ***

Comment 24

[Nitin (vfwlkr)]

*** Bug 209903 has been marked as a duplicate of this bug. ***

Comment 25

[Nitin (vfwlkr)]

reassigning bug to current owner/QA of tabbed browser component.

Comment 26

[R.K.Aa.]

*** Bug 238198 has been marked as a duplicate of this bug. ***

Comment 27

[Prognathous]

*** Bug 245786 has been marked as a duplicate of this bug. ***

Comment 28

[Rastignac]

OK. My idea is:

- When there are more than one tab, the button is [x] and close the current tab.

- When there is only one tab, the button changes to something different (let's
say [/] for example) and hide the tab bar.

I think it's good.

Comment 29

[Nitin (vfwlkr)]

What about middle-click to close the last open tab?

Comment 30

[Niels Basjes]

(In reply to comment #28)
> - When there is only one tab, the button changes to something different (let's
> say [/] for example) and hide the tab bar.

I disagree with this suggestion. From a usability standpoint I think it is
confusing for the user when a menu item or button at a specific location changes
function. That is why menu and dialog items that are not applicable are greyed
out instead of removed.

My suggestion would therefor be:
- many tabs: [X] closes the currently shown tab.
- 1 tab: [X] closes the currently shown tab. I feel that logic dictates that the
 window should be closed as well. Hiding the tab bar defies logic.

Comment 31

[Ariel Arjona]

I agree with comment #30. 
I think that the best option is to close que whole window, as it happens if one
uses the keyboard shortcut (Ctrl W). The second best would be to simply disable
the button when there's only one tab open.

Comment 32

[dolphinling]

A while ago on the newsgroups this subject was discussed. IIRC (big if) the
verdict was about equally split between closes the tab, leaves no tabs open,
closes the tab, opens a new tab with a blank page, and closes the window.

I see things as follows: when I click the close tab button, I am expecting the
tab to close /and/ I am expecting the tab behind it to be revealed. That's what
happens every other time. This is a slightly special case, since there is no tab
behind it to be revealed; therefore, logic dictates it should be closed and
nothing else revealed, but usability dictates that another tab should be opened
since having no tabs open is useless and since in every other case I am
expecting another tab to be there. 

I definitely do not expect the window to be closed. If I wanted the window to
close, I would use the button the OS provides. This is easier (it's nearly
always in a corner of the screen if the window is maximized or in an area of
higher contrast and therfore easier to pick out if the window is not) and is the
standard way of doing things. Also, if the tab button closes the window, then
/every single time/ I want to close a tab, I have to think "Will this close the
whole program?" since I don't want the whole program closed, I just want that
tab closed. As minor as that is to check, doing it every single time will get
quite annoying. 

Comment 33

[dolphinling]

I believe the code causing this would be one of these:
http://lxr.mozilla.org/mozilla/search?string=removeCurrentTab , most likely
http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/tabbrowser.xml#849
and/or
http://lxr.mozilla.org/mozilla/source/xpfe/global/resources/content/bindings/tabbrowser.xml#959
but don't take my word for it.

Comment 34

[Sergei Haller]

(In reply to comment #31)
> I agree with comment #30. 
> I think that the best option is to close que whole window, as it happens if one
> uses the keyboard shortcut (Ctrl W). The second best would be to simply disable
> the button when there's only one tab open.

I fully agree. where "disable the button" means "gray out the button"

Comment 35

[guanxi]

If you want to debate the merits of bugs, including advocating one resolution or
another, please use a forum such as newsgroups or mozillazine forums.

Bugzilla isn't the place for it.

Comment 36

[Nitin (vfwlkr)]

Just an fyi for those who are waiting for this (even more so because this bug
isnt assigned yet), there is an extension that fixes this bug:
http://update.mozilla.org/extensions/moreinfo.php?id=175&vid=334&category=

Comment 37

[Jason Bassford]

Unfortunately, that XPI doesn't install for me.  I go to install it, and I'm
told "install script not found" - whatever that means...  (7/23-07 under XP.)

I do like the fact that somebody's working on an XPI, however.  If I'm not
mistaken, it makes it fairly simple to convert it into an actual patch.

Comment 38

[Patrick]

fmannino: why do you remove the MINUS flag on the blocking-aviary1.0? The
decision was made by the appropriate person and since his decision on July 3, no
additional work has been done on this bug?

Setting the minus flag back again. If you DO want Blake to reconsider, than add
some comments as to why you re-request a blocking flag.

Comment 39

[Brodie]

Clicking that button is actually closing the tab, but the semantics behind it is
more about stopping viewing the currently displayed page.

When a user clicks that button they are most likely meaning, "I'm done with this
page. I don't want to view it anymore. Get rid of it." 

Therefore behaviour should be:
2+ tabs = stop displaying the current page 
  (close the tab, show the next tab in order)
1 tab = stop displaying the current page 
  (replace the current page with about:blank)

The button should not ever be overloaded with behaviour to remove the tab bar.
The correct place to determine if the tab bar is shown or not is a menu and/or
preferences screen.

If the tab close button is going to be disabled at any time, it should only be
when there is only 1 tab left, AND that tab is displaying about:blank. Users
WANT to be able to stop viewing that last page.

Comment 40

[Daniel Clemente]

Comment 39: that seems a good solution.
 Other proposed solutions do other things than closing the page, or create
different functionalities for the same button. Also, this does not modify the
visibility of the tab bar.
 Can anyone think of a better one?

Comment 41

[Sergei Haller]

I fully agree to comment #39 where

> 2+ tabs = stop displaying the current page 
>   (close the tab, show the next tab in order)

"the next tab in order" should be "in chronological order",
i.e., in order they wer viewed last.

Comment 42

[Daniel Clemente]

Comment 41: that would be another bug which requires a lot of discussion.
Something like "go to the last viewed tab when current tab is closed".

Comment 43

[Sergei Haller]

(In reply to comment #42)
> Comment 41: that would be another bug which requires a lot of discussion.
> Something like "go to the last viewed tab when current tab is closed".

you're right: this is bug 105722

Comment 44

[Nitin (vfwlkr)]

same bug for firefox (now fixed): bug 248987

Comment 45

[Tracy Walker [:tracy]]

this is fixed in bug 248987. 
the decision there was to about:blank the last tab if the user clicked the [x]
to close the last tab. 

marking this a dupe since the fix was attached there.

*** This bug has been marked as a duplicate of 248987 ***

Comment 46

[Jason Bassford]

Bug 248987 is Firefox specific and has nothing to do with the Mozilla browser -
which this bug is filed again.

Reopening.

Comment 47

[n0dalus]

Attachment: Blanks last tab instead of hiding the Tab Bar if "Hide Tab Bar" option is unticked

This is the approved patch I wrote for Firefox in bug 248987, modified for
Mozilla.
I don't have Mozilla to check that it works, but I dont see why it wouldn't.

Comment 48

[Daniel Clemente]

> this.loadURI("about.blank");

It's about:blank

Comment 49

[n0dalus]

Attachment: Blanks last tab instead of hiding the Tab Bar if "Hide Tab Bar" option is unticked

Sorry about the typo.

Comment 50

[Asaf Romano (gone)]

Comment on attachment 160372 [details] [diff] [review]
Blanks last tab instead of hiding the Tab Bar if "Hide Tab Bar" option is unticked

requesting r/sr for your patch.

Comment 51

[jag (Peter Annema)]

Comment on attachment 160372 [details] [diff] [review]
Blanks last tab instead of hiding the Tab Bar if "Hide Tab Bar" option is unticked

Erh, you shouldn't have to check the autohide pref, if that is set to true,
with only one tab left the bar is hidden and there's no close box to click.
This reveals the dead code resulting from this patch, namely the code that
would force the tab bar to hide. And with that gone the rest of the code
dealing with browser.tabs.forceHide can also be removed / amended.

That said, let me think about the desired effect of this patch. I'll get back
to you on this.

Comment 52

[[e-mail]]

(In reply to comment #51)
>This reveals the dead code resulting from this patch, namely the code that
>would force the tab bar to hide. And with that gone the rest of the code
>dealing with browser.tabs.forceHide can also be removed / amended.
Does that include View Show/Hide Tab Bar?

Comment 53

[Brodie]

As far as I can see, this patch should be as follows.

var l = this.mTabContainer.childNodes.length;
if (l == 1) {
  if (this.mPrefs.getBoolPref("browser.tabs.autoHide")) {
    // this should only ever happen if the pref was changed while 
    // there was only a single tab displayed.
    this.setStripVisibilityTo(false);
  } else {
    // blank the last tab
    //TODO: remove tab history
    this.loadURI("about:blank");
  }
  return;
}


This will hide the tab-bar if autohide is true, and just blank it otherwise. We
don't want to force autohide to true at any time.

Comment 54

[OstGote!]

*** Bug 304775 has been marked as a duplicate of this bug. ***

Comment 55

[Nick_Jenkins]

Cross-reference to code shown in bug 236721 comment 21.

Notes:
* You always want to do loadURI("about:blank") if there is only one tab left
open. How the user has the tab-hiding set up is simply irrelevant to this, and
the current code gets this wrong (i.e. if you only have one tab left open, and
you don't have autohide on, then currently it won't close the current tab, which
is simply wrong).
* You always want to purge the session history too (see code at above cross
reference for how to do this).
* Brodie may well be correct about not setting the forceHide preference. I
haven't looked into this, and simply rearranged the existing code when it came
to this. So perhaps the 'setBoolPref("browser.tabs.forceHide", true)' line
should be deleted.

Comment 56

[Jason Bassford]

See my original comment 20.  Having about:blank when clicking on the last tab
replaces one set of inconsistent results with yet another, making the overall
situation no better than before.  If that is the final solution, then should a
further bug be filed so that Ctrl-W gives you about:blank also?  (Although, I do
note that you can now use the context menu on the last tab to get the same
results as the tab close button - it's no longer greyed out.  I'm not sure when
that behaviour changed, but it's a step in the right direction of consistency.)

Comment 57

[Nitin (vfwlkr)]

Changing module to mozilla application suite, since firefox already has a fix
(via bug 248987)

Comment 58

[Mario]

*** Bug 313416 has been marked as a duplicate of this bug. ***

Comment 59

[Peter Weilbacher]

*** Bug 322326 has been marked as a duplicate of this bug. ***

Comment 60

[Andrew Schultz]

*** Bug 326395 has been marked as a duplicate of this bug. ***

Comment 61

[tech]

as bug #326395 as been marked a duplicate of this one which is more than three years old, I re-post its decription here as it doesn't seems to me that it's the same.

submited bug #326395 Opened: 2006-02-08 04:29

User-Agent:       Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1)
Gecko/20060130 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1)
Gecko/20060130 SeaMonkey/1.0

on the last release of seamonkey I installed, it's impossible to close the
first tab even when other tabs are opened.
When it's the only tab this action hides the tab bar


Reproducible: Always

Steps to Reproduce:
1.a web page
2.open another page in the second tab
3. try to close the first tab

Comment 62

[tech]

I've just tried with a new profile and all is working now, even other problems on bugs I've submited are gone, I'm going to reinstall one by one the extensions I have in my profile to try to identify the problematic one

> as bug #326395 as been marked a duplicate of this one which is more than three
> years old, I re-post its decription here as it doesn't seems to me that it's
> the same.
> 
> submited bug #326395 Opened: 2006-02-08 04:29
> 
> User-Agent:       Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1)
> Gecko/20060130 SeaMonkey/1.0
> Build Identifier: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.8.0.1)
> Gecko/20060130 SeaMonkey/1.0
> 
> on the last release of seamonkey I installed, it's impossible to close the
> first tab even when other tabs are opened.
> When it's the only tab this action hides the tab bar
> 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1.a web page
> 2.open another page in the second tab
> 3. try to close the first tab
> 

Comment 63

[jan honsberg]

maybe Bug 154849 is an duplicate?

Comment 64

[OstGote!]

*** Bug 154849 has been marked as a duplicate of this bug. ***

Comment 65

[OstGote!]

*** Bug 322326 has been marked as a duplicate of this bug. ***

Comment 66

[Andrew Schultz]

tabbed browser, no?

Comment 67

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Taking... this is low priority for me so feel free to swipe the bug and fix it yourself :).

Comment 68

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: blank last tab

Same as the Firefox implementation.

Comment 69

[[e-mail]]

Comment on attachment 233414 [details] [diff] [review]
blank last tab

This will cause me dataloss, because I'm used to X hiding the tab bar...

>             var l = this.mTabs.length;
>-            if (l == 1) {
>-              // hide the tab bar
>-              this.mPrefs.setBoolPref("browser.tabs.forceHide", true);
>-              this.mStrip.collapsed = true;
>-              return;
>-            }
Move the var l to where you use it. sr=me with this fixed.

Comment 70

[Bruno 'Aqualon' Escherl]

The new behaviour is inconsistent to the behaviour of Ctrl+W. If you press Ctrl+W on the last tab and browser.tabs.autoHide is set to true, the browser window gets closed and I expect the same from the close box.

Comment 71

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #70)
> The new behaviour is inconsistent to the behaviour of Ctrl+W. If you press
> Ctrl+W on the last tab and browser.tabs.autoHide is set to true, the browser
> window gets closed and I expect the same from the close box.
> 

Hmmm... Firefox doesn't let you quit with Ctrl+W.  Jag?  Neil?  Do you think we should make ^w match the behavior of clicking the "X" like Firefox?

Comment 72

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #71)
> (In reply to comment #70)
> > The new behaviour is inconsistent to the behaviour of Ctrl+W. If you press
> > Ctrl+W on the last tab and browser.tabs.autoHide is set to true, the browser
> > window gets closed and I expect the same from the close box.
> > 
> 
> Hmmm... Firefox doesn't let you quit with Ctrl+W.  Jag?  Neil?  Do you think we
> should make ^w match the behavior of clicking the "X" like Firefox?

And should it be based on the pref? (i.e. should ctrl+w close the browser if you choose to hide the tab bar?)

Comment 73

[[e-mail]]

^W should always close the window if only one tab is left.

Comment 74

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Fixed on trunk.

Comment 75

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 233414 [details] [diff] [review]
blank last tab

changing to 1.1b as alpha was released

Comment 76

[Serge Gautherie (:sgautherie)]

(In reply to comment #71)
> Hmmm... Firefox doesn't let you quit with Ctrl+W.  Jag?  Neil?  Do you think we
> should make ^w match the behavior of clicking the "X" like Firefox?

On single tab, with tab bar shown,
more than being inconsistent with FireFox (which might be our choice.?!.),

(In reply to comment #73)
> ^W should always close the window if only one tab is left.

SeaMonkey has an issue in the File menu:
it reads "Close Tab / Ctrl+W" and "Close Window / Ctrl+Shift+W";
but, while the tab bar "X" closes the tab,
Ctrl-W or its menu item closes the window :-(

I believe the FireFox behaviour (== do what the menu says) is what we want too on this point !?

Comment 77

[[e-mail]]

(In reply to comment #76)
>SeaMonkey has an issue in the File menu:
>it reads "Close Tab / Ctrl+W" and "Close Window / Ctrl+Shift+W";
>but, while the tab bar "X" closes the tab,
>Ctrl-W or its menu item closes the window :-(
Actually SeaMonkey always used to do this when the tabbar was visible...
I'd prefer (in a separate bug) to make the menuitems track the actions.

Comment 78

[Serge Gautherie (:sgautherie)]

I filed bug 351428 about comment 77 (and comment 72).

Comment 79

[Benoît]

Wouldn't it be more logical to grey out the "Close Tab" option and not react on Ctrl+W when there is only one tab without tab bar? It doesn't seem right that closing the last tab should close the entire window, there's another option for that.

Comment 80

[[e-mail]]

Ctrl+W closes the window everywhere else. It was only changed for tabbrowser because it was thought more useful for people using tabs instead of windows.

Comment 81

[Asaf Romano (gone)]

Not in win32 MDI windows IIRC (Now, do we consider tabbrowser windows pseudo-MDI?). Also, and again IIRC (and FWIW ;)) this was changed in IE7 and NS8.

Comment 82

[[e-mail]]

We have two categories of users. Some never use tabs and never will. For them, we have to make Ctrl+W close the window like it does (or should do, at least) everywhere else *in SeaMonkey* while for those people who have migrated from windows to tabs we need Ctrl+W to close the current tab instead.

Comment 83

[Asaf Romano (gone)]

In Fx, Accel+W closes the window unless "Always show the tab bar" is ticked, in which case we destroy-and-create the first tab like the patch here does.

Comment 84

[[e-mail]]

I don't think that would be right. What I could live with is that pressing Ctrl+W would close the window if the tab bar is hidden (in SeaMonkey there are three reasons that this could be the case.)

Comment 85

[Asaf Romano (gone)]

yeah, ugh, we do close popup windows on Accel+W regardless of the pref.

Comment 86

[[e-mail]]

I guess the "Close Tab" in the tab context menu should always be enabled?

Comment 87

[Worcester12345]

(In reply to comment #86)
> I guess the "Close Tab" in the tab context menu should always be enabled?
> 

Please!