191818 - File menu missing "Close other tabs" option

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[NorthMan]

User-Agent:       Mozilla/5.0 (Windows 2003 Government Server Edition; en-US) Gecko
Build Identifier: 2003020308

File menu missing "Close other tabs" option

Looking for the "close other tabs" function to be inserted in under File menu.

A "Close other tabs" menu item (should be under the File menu, under Close Tab,
but above Close Window) really wasn't needed until bug 103354 was "fixed". 
Close other tabs is a popular feature, and if bug 191492 (modifier key solution)
is fixed, the menu item will not be necessary, but would be beneficial to those
who do not know the modifier+close tab combo.

Many people use the Close other Tabs feature, and I agree with bug 103354.  It
was in a sometimes dangerous spot, right below close tab, but personally I
always used the close tab button.  Removing the feature from that place was a
*good* idea, but removing it /entirely/ from Mozilla is a *bad* idea.

Reproducible: Always

Steps to Reproduce:

Comment 1

[jag (Peter Annema)]

Agree.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Well... this should be a simple PatchMaker patch, no?  Someone care to provide
and I'll review?  ;)

Comment 3

[Peter Lairo]

I still think bug 191578 is the best solution, but this is also a good solution.

Comment 4

[Bernard Alleysson]

How do you prevent people from accidentally choosing File | Close All Tabs
instead of File | Close Tab ?

Comment 5

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

if someone fixes this, please make sure that this menuitem only shows up if you
have >= 2 tabs open.

Comment 6

[Peter Lairo]

> menuitem only shows up if you have >= 2 tabs open.

It should be *grayed out* (just like other currently non-applicable menu items).

> prevent accidentally ... File | Close *OTHER* Tabs instead of File | Close Tab?

By adding a confirmation dialog to "Close Other Tabs". (BTW, this would be just
like when you have a mail *folder* selected, but it *and* a messages are
highlighted, and your press DELETE.) See bug 191578. :-\

Comment 7

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

It should be hidden, just like "Close Tab" is hidden.

Comment 8

[Peter Lairo]

What about Edit | Fill in Form & Save Form Info? There must be some rule/logic
to deciding whether to hide or gray out a menu item. 

My preference is that menu items not shift (by not hiding them) and that
functions (even currently unaccessible ones) remain "discoverable & learnable"
at all times. € 0.02

Comment 9

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

_my_ preference is that I never see tabs-related menuitems, as I have no use for
them.

Comment 10

[Jason Bassford]

> It should be hidden, just like "Close Tab" is hidden.

The File menu item "Close Tab" is only hidden if you've set the preference to
not show a single tab.  If you DO show a single tab, then the menu item appears.

Therefore, I believe that if you are viewing tabs at all (even a single one)
that the item should appear.  Of course, as mentioned, it should be greyed out
if there is only a single tab in use.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> What about Edit | Fill in Form & Save Form Info?

What about them?  They belong to one of the worst parts of Mozilla's UI -- the
form manager.  Emulating them is not the way to go.

Comment 12

[Peter Lairo]

Edit | Fill in Form & Save Form Info were merely examples of grayed out menu
items. I could have just as well used: Edit| Redo, Cut, Copy, Paste, and Delete
- all of which are grayed out when not applicable. Comment #10 is the most
reasoned so far.

Comment 13

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

>The File menu item "Close Tab" is only hidden if you've set the preference to
>not show a single tab.

ok then, so "close other tabs" should also be idden if I've set that preference.

Comment 14

[Jason Bassford]

> ok then, so "close other tabs" should also be hidden
> if I've set that preference.

Correct.  Just as with "Close Tab", if you've set the preference to not show a
single tab, all tab related menu items (such as "Close Other Tabs") should be
hidden.  However, if tabs *are* being displayed (even a single one), all tab
menu items should appear - and be greyed out where appropriate.

Comment 15

[jag (Peter Annema)]

To summarize: for consistency, the "Close Other Tabs" item should be hidden when
the tab bar is hidden, and greyed out when only one tab is open in its
containing window. Anyone wanna save me some trouble and turn that into a patch?

I know I still need to address the "show a confirmation dialog on Close Other
Tabs" issue, let me do that elsewhere, not in this bug. I'll deal with it before
we land any patch for this bug though.

Comment 16

[[e-mail]]

Got this working - just need to put the strings in dtd/properties.

Comment 17

[Peter Lairo]

For those thinking this File Menu bug is an inferior (yet still welcomed)
workaround for the removal of *Close Other Tabs*, see bug 191826 (woohoo).

Comment 18

[[e-mail]]

Attachment: Proposed patch

Comment 19

[sairuh (rarely reading bugmail)]

if this added, a menu acces key will be needed; see bug 135567 for discussion there.

Comment 20

[Jesse Ruderman]

I think the tab context menu is a better place than the file menu for the "close
other tabs" command.  The File menu is long, it's a smaller target than tabs,
and having "Close other Tabs" on the File menu will make the menu change more
than it already does depending on whether you have multiple tabs open.

Fixing bug 191826 ("close tab" should be at top of tab context menu) should take
care of most of the accidental hitting of "close other tabs" that led to its
removal.

Comment 21

[Jason Bassford]

> Fixing bug 191826 ("close tab" should be at top of tab context menu)
> should take care of most of the accidental hitting of "close other tabs"
> that led to its removal.

As I mentioned in bug 191826 comment 4, I believe that positioning Close Tab
(and Close Other Tabs) at the top of the list, closest to the mouse when doing a
right-click, will only result in MORE dataloss from accidental clicks on the
link - and also on the normal Close Tab this time too.

Having it in the File menu is the better choice if the goal is purely to prevent
accidental closure.

Comment 22

[Clark]

THis was a feature that I used regualarly. I would access it by right clicking
my desired tab.  It is an inconvenience to see it gone.

Comment 23

[Adam Lock]

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

Comment 24

[Ray Charbonneau]

This needs to go back in the context menu.  It might be good to have it in the
File menu under general UI principles, but the context menu is where it's _useful_.

Comment 25

[Adam Lock]

Nominating as 1.3 blocker. It makes tabbed browsing extremely inconvenient.

Comment 26

[Adam Lock]

Reinstating request. Please let the drivers decide the blocking status

Comment 27

[Asa Dotzler [:asa]]

Neither this bug nor bug 191826 are something we'd hold the release for. That's
not to say that a patch wouldn't be approved. 

Comment 28

[jag (Peter Annema)]

I would like to get this implemented for 1.3 final, together with bug 191826.

Neil, your patch is okay, but I'd prefer to put back some of the code that was
removed for bug 103354 and use that for both this bug and bug 191826. I could do
this, or you could, since it shouldn't be much more work than undoing that
backout and reordering the context menu's items as per the new spec.

Instead of copying the "Close" string in the .properties file, could we take the
value of the menu's label and store/restore that instead? Otherwise I think we
should add a comment in the .properties file pointing to the .dtd file/value
it's a copy of.

I'll take a closer look at the new patch.

Comment 29

[[e-mail]]

And here was me thinking you would have a go at me for blindly making the
commented dependency worse.

Oh, and the reason that my removeAllTabsBut code is different is that I test
Mozilla on a 133Mhz PC and the code I provided appears to be more efficient.

Comment 30

[jag (Peter Annema)]

Taking another look then :-)

Comment 31

[jag (Peter Annema)]

Comment on attachment 113800 [details] [diff] [review]
Proposed patch

sr=jag

Are you actually making tabbrowser depend more on the close menu items (not
seeing this), or were you thinking I thought you were? (Confused yet?)

Comment 32

[[e-mail]]

Um, neither, I think...

Comment 33

[jag (Peter Annema)]

Then I'm confused :-)

Comment 34

[Thomas E. Link]

I need this menu item back! This is a release-stopper as far as I am concerned.

Tom Link

Comment 35

[Asa Dotzler [:asa]]

Comment on attachment 113800 [details] [diff] [review]
Proposed patch

a=asa (on behalf of drivers) for checkin to 1.3.

Comment 36

[[e-mail]]

Fix checked in, but Asa says this broke Phoenix. Need to CC some phoenix gurus.

Comment 37

[Jan Varga [:janv]]

I don't think this patch broke Phoenix.
Looks like mcafee is testing something.
http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest

Comment 38

[Pierre Chanial]

Phoenix still relies on the tabbrowser property files. Moving some string
bundles from tabbrowser.properties to navigator broke it. It's our fault, I'll
fix it right now.

Comment 39

[[e-mail]]

pch, please can you close this off once Phoneix is fixed?

Comment 40

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

can you guys move the phoenix discussion to another bug?

Comment 41

[Pierre Chanial]

The bustage is fixed in Phoenix (issue tracked in bug 194099).
Credits back to Neil :)

Comment 42

[[e-mail]]

Fixed.

Comment 43

[flii (cj)]

i'd like to put my vote in for close other tabs to be back in the context menu.
 i just installed the 2003-02-21 nightly, replacing my 2003-01-26, and i greatly
miss this option.

Comment 44

[NorthMan]

:-) Verified fixed Win32 2003022108.