File menu missing "Close other tabs" option

VERIFIED FIXED

Status

SeaMonkey
Tabbed Browser
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: NorthMan, Assigned: neil@parkwaycc.co.uk)

Tracking

Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

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

Comment 3

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

Comment 4

16 years ago
How do you prevent people from accidentally choosing File | Close All Tabs
instead of File | Close Tab ?
if someone fixes this, please make sure that this menuitem only shows up if you
have >= 2 tabs open.

Comment 6

16 years ago
> 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. :-\
It should be hidden, just like "Close Tab" is hidden.

Comment 8

16 years ago
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
_my_ preference is that I never see tabs-related menuitems, as I have no use for
them.

Comment 10

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

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

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

16 years ago
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.
Keywords: nsbeta1
(Assignee)

Comment 16

16 years ago
Got this working - just need to put the strings in dtd/properties.
Assignee: jaggernaut → neil

Comment 17

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

Comment 18

16 years ago
Created attachment 113800 [details] [diff] [review]
Proposed patch
if this added, a menu acces key will be needed; see bug 135567 for discussion there.

Comment 20

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

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

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

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

Comment 24

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

16 years ago
Nominating as 1.3 blocker. It makes tabbed browsing extremely inconvenient.
Flags: blocking1.3?

Updated

16 years ago
Flags: blocking1.3? → blocking1.3+

Updated

16 years ago
Flags: blocking1.3+

Comment 26

16 years ago
Reinstating request. Please let the drivers decide the blocking status
Flags: blocking1.3?

Comment 27

16 years ago
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. 
Flags: blocking1.3? → blocking1.3-

Comment 28

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

Comment 29

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

16 years ago
Taking another look then :-)

Comment 31

16 years ago
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?)
Attachment #113800 - Flags: superreview+

Updated

16 years ago
Attachment #113800 - Flags: review?(shliang)

Updated

16 years ago
Attachment #113800 - Flags: review?(shliang) → review+

Updated

16 years ago
Attachment #113800 - Flags: approval1.3?
(Assignee)

Comment 32

16 years ago
Um, neither, I think...
Status: NEW → ASSIGNED

Comment 33

16 years ago
Then I'm confused :-)

Comment 34

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

Tom Link

Comment 35

16 years ago
Comment on attachment 113800 [details] [diff] [review]
Proposed patch

a=asa (on behalf of drivers) for checkin to 1.3.
Attachment #113800 - Flags: approval1.3? → approval1.3+
(Assignee)

Comment 36

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

Comment 37

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

Comment 38

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

Comment 39

16 years ago
pch, please can you close this off once Phoneix is fixed?
Assignee: neil → chanial
Status: ASSIGNED → NEW
can you guys move the phoenix discussion to another bug?

Comment 41

16 years ago
The bustage is fixed in Phoenix (issue tracked in bug 194099).
Credits back to Neil :)
Assignee: chanial → neil
(Assignee)

Comment 42

16 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 43

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

Comment 44

16 years ago
:-) Verified fixed Win32 2003022108.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.