351428 - When there is only 1 tab and the tab bar is shown, the file menu is inconsistent

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Serge Gautherie (:sgautherie)]

From bug 156082 comment 77:
[
 ------- Comment #77 From [e-mail]  2006-09-05 05:38 PDT  [reply] -------

(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.
]

Indeed: I checked MASv1.7.13 and SMv1.0.4.

Then, this bug is about getting the "Close / Ctrl+W" item (only), when there's a single tab, whether the tab bar is shown (or not).

***

I still feel the ("new") FireFox way is fine,
but since I'm not actually affected by this case, I won't try and argue much.

Still, as ChrisT suggested in bug 156082 comment 72:
We could add a preference to match the FireFox behavior(s): "X" button, Ctrl+W cases, ... !?
(for SeaMonkey users who would prefer it; or for FireFox users who would switch app. (;-)); ...)
We could even use it to change the default behavior of new profiles.

(Now, you decide.)

Comment 1

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

That's not actually what I was asking in bug 156802 comment 72.  I was asking whether the behavior of ^W should depend on the "always show tab bar" pref, not some new pref.

My current gut feeling is that we should hide close tab and close other tabs, and show close window with a hotkey of ctrl+w (rather than ctrl+shift+w) if there is only one tab open and you're showing the tab strip.  Neil, what do you think?

Comment 2

[[e-mail]]

That's fine by me.

Comment 3

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

Attachment: patch

Actually this only disables close tab.  I left it visible because it shows that ctrl+w is a hotkey that exists, but is disabled (which matches the behavior of ctrl+w doing nothing).

Comment 4

[[e-mail]]

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

You never re-enable cmd_close and I'm not sure I like this (but feel free to ask jag for sr next time if you want this style).

Comment 5

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

Attachment: v2

Comment 6

[[e-mail]]

Comment on attachment 237502 [details] [diff] [review]
v2

CTho, I did say to ask jag for sr if you wanted to disable Ctrl+W when one tab is visible in the tab strip.

Comment 7

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

(In reply to comment #6)
> (From update of attachment 237502 [details] [diff] [review] [edit])
> CTho, I did say to ask jag for sr if you wanted to disable Ctrl+W when one tab
> is visible in the tab strip.
> 

Oh, sorry, I forgot what I said in comment 1.  I'll think about a version that does that too.

Comment 8

[jag (Peter Annema)]

As a keyboard user, I'd rather have ctrl+w (cmd+w) close the window. Or rather, close the last tab, and have the tab-less window go "Poof!" (yep, with sound and visual effects). I'd be ok with having the File menu show just "Close   ctrl+w" for the last visible tab.

Comment 9

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

(In reply to comment #8)
> As a keyboard user, I'd rather have ctrl+w (cmd+w) close the window. Or rather,
> close the last tab, and have the tab-less window go "Poof!" (yep, with sound
> and visual effects). I'd be ok with having the File menu show just "Close  
> ctrl+w" for the last visible tab.

Have you seen/tried the Firefox2 behavior?

Comment 10

[jag (Peter Annema)]

Hrmpf. I guess having the tab's close button and ctrl+w be consistent is a good thing, but I'm not sure I like the behaviour. Personally I would've made closing the last tab close the window.

Comment 11

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

Attachment: another version

^W closes the window now :(

Comment 12

[jag (Peter Annema)]

Comment on attachment 237881 [details] [diff] [review]
another version

This would be my preference, but I'm not sure I get to make these kind of calls by myself. What do other UI people think of this?

Comment 13

[[e-mail]]

Comment on attachment 237881 [details] [diff] [review]
another version

>-    document.getElementById('menu_close').setAttribute('label', gNavigatorBundle.getString('tabs.closeTab'));
moa+r=me if you move this instead of deleting it ;-)

Comment 14

[[e-mail]]

Comment on attachment 237881 [details] [diff] [review]
another version

As per comments 12 and 13.

Comment 15

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

Fixed on trunk.  a?

Comment 16

[Robert Kaiser]

Comment on attachment 237881 [details] [diff] [review]
another version

a=me given it works as expected on trunk.

Comment 17

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

Fixed on branch.  Please verify it in the next nightly build.

Comment 18

[Håkan Waara]

Was this supposed to be checked into the Attic?

mozilla/xpfe/browser/resources/content/Attic/navigator.js

I think that's some special CVS thingy...

Comment 19

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

(In reply to comment #18)
> Was this supposed to be checked into the Attic?
> 
> mozilla/xpfe/browser/resources/content/Attic/navigator.js
> 
> I think that's some special CVS thingy...

Files that were removed on the trunk but that still exist on the branch live in the Attic, that's expected.

Comment 20

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20061001 SeaMonkey/1.1b] (nightly) (W98SE)

V.Fixed on MOZILLA_1_8_BRANCH.