Closed Bug 117077 Opened 23 years ago Closed 15 years ago

Improve visual association of 'X' close button with current tab (suite)

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 534221

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: Make browser.tabs.closeButtons work)

Attachments

(10 files, 1 obsolete file)

'X' button in it's own tab
57.79 KB, image/png
Details
'X' button with raised outline
57.81 KB, image/png
Details
Dedicated space for tab controls
36.99 KB, image/png
Details
Different tactic, mouseover toolbar...
37.67 KB, image/png
Details
All controls in 1 spot
36.33 KB, image/png
Details
Combination space & mouseover
37.42 KB, image/png
Details
Dedicated control area, Icons aligned
37.54 KB, image/x-png
Details
X is in Tabs. Ignore the erroneuous X under the URL. I didn't see that until after I posted it.
17.58 KB, image/png
Details
Close button in each tab
22.75 KB, image/png
Details
Safari's approach to the tab close button
25.50 KB, image/png
Details 
The 'X' close button should be easily associated with the current tab.  As it is
it just sort of floats in the tab field.  Even after much use I still have to
think to make myself use it.
Two possible answers that I can see:
1. Put the X on the current tab itself.
2. Create a special tab at the right for connecting the X.
Pictures to follow.
Doesn't matter to me which one is done.  The only reason I suggest number 2 is
to save space on the tab itself for the page title.
Attached picture of 'X' close button in it's own tab.
This is the same picture with a raised outline around the button, ie mouseover.
Regarding "1. Put the X on the current tab itself" see 108938.

As for comment 3 (outline), it seems to be a duplicate of bug 104834 (which was
fixed one week ago, but couldn't verify, I am running 2001121803). Reporter, can
you check with more recent build? See also bug 113879 (tooltip).

The implementation as shown is nice. As a drawback let's note that we loose
vertical space, but not much.

To summarize I recommend bug owner to keep the summary but change bug
description as follow:
"alternative to bug 108938, if we decide to keep a unique close tab button, add
a visual effect that associates it with the current tab".

Some dependencies between the two bugs should be enforced.
I like the picture in comment 2. I was going to suggest something similar
myself. I'm voting for the suggestion in comment 2.

>As for comment 3 (outline), it seems to be a duplicate of bug 104834
Actually comment 3 is intended to be the mouseover effect of comment 2.  It
should behave similarly to the menus on mouseover.  The fix for bug 104834
created a permanent outline and a highlight on mouseover.
"1" is covered by bug 108938; that might be the most elegant choice, but this is
a compromise to save some space on the tabs.
Summary: Improve visual association of 'X' button with current tab → Improve visual association of 'X' close button with current tab
Target Milestone: --- → Future
To improve the visual association between the tab and the close button, I think
moving the close button to the active tab would be best.  See also bug 108938.

I agree with comment 6.
i also agree to #6
This is a valid feature request, and imho much better designed than bug 108938
. This is because you won't accidentally click the "X" while playing around with
the tabs and also because it won't take up extra room.

Please take this off the uncomfirmed radar.
Indeed, there's no reason for this to stay UNCO
Status: UNCONFIRMED → NEW
Ever confirmed: true
I agree with #9. I see at least one drawback: we cannot close a non displayed
tab using this solution.
Jerome - you can always close a non-displayed tab by right clicking on it and
selecting 'close tab' from the context menu.

Gabriel, that's true but you then need one more step (the right menu). 
When you ask people who are not familiar with GUI, they usualy don't know about
the right button contextual menus. But you're right: the functionality is still
there. Just a little bit more difficult to access.
Jerome: The risk of having an "X" on a tab right near where you click your mouse
to bring it to the front it is just asking for you to accidentally close a tab.
Also, closing tabs that aren't visible is made possible by middle clicking on
them. (Well, at least it will be when Bug 107147 gets fixed).

There is another bug about putting the X on every tab (Bug 108938) where many
pros and cons were pointed out. One of the main problems that I see, is when
opening several tabs, the "handles" get so small you'll have to be careful where
you click. Of course, there should be a minimum size to a tab, but that just
brings Bug 106927 which point out that we have no way of dealing with "too many"
tabs.


This bug gets my vote, it makes the browser more intuitive, something all UIs
strive to, yet steering clear of possible "presision clicking" problems.
I completely agree that the [x] needs to have much better ownership of the tab
it's going to close, etc..

IMO, making it look like another tab isn't exactly pretty and could still cause
some confusion.

I think the main reason for this is the [X] really needs it's own spot in the
tab interface, but that spot currently doesn't exist (there's no area
specifically set aside for tab-specific controls).

I've come up with 3 ideas that I think could really help this issue...
This is an example of where the dedicated tab control space probably *should*
be, but because it takes up a lot of extra room, it's probably not really
usefuul.  Just illustrating the point of needed a space for this stuff.
Attached image Dedicated control area, space saver (obsolete) — 
Here's a variation on the previous image, but this time saving space while not
making the X look like it's another tab.
Here's a 3rd idea, which instead of always getting it's own space, would
provide controls when they are needed, and hide them when their not.

The toolbar would be activated on a mouseover of the tab, on both active and
non-active tabs.  This keeps it out of the way, prevents accidental clicking
when you are just trying to change tabs, and allows for the functionality to
work on non-active tabs - all things that people have been talking about (some
issues that were brought up in bug 108938)
Brian's last two are quite nice. 90236 looks a bit off since the close button is
fixed slightly lower then new tab button. Might look messy.
Attached image All controls in 1 spot — 
Mainly illustrating where dedicated tab controls could live.  Here's a revised
version, with all controls in one place.  Additional controls that make sense
could also live in this area.
Attachment #90236 - Attachment is obsolete: true
Both of these could also be combined.  There's some redundancy here, but it
does address these issues:
- main tab controls in 1 place
- ability to close/reload all open tabs using the mouse without having to focus
the tab first
- keeps dangerous actions out of accidental clicking area
- doesn't use up much space - allows for many tabs to be open without
cluttering up controls

Remember, the "drawer" is only visible when there is a mouseover on the tab
For those who've never used MultiZilla, it has a tab mouseover effect which
replaces the tab icon with the 'X' to close.  This works on any tab, so you can
easily close a non-active tab.  I think this would be a good compromise, since a
tab reload button is probably not necessary.
As an original proponent of "x on tab" (bug 108938), and now just trying the
multizilla interface (thanks for hijacking all my prefs multizilla!), I am now
convinced that the X should not be on the tab.

It is very easy to accidentally close a tab with the X on the tab itself.  I
accidentally did it 2 times in the 5 minutes I was using it.  IMO, it would be
better to have no button there than one that causes accidental closings.

There has been much discussion of this in bug 108938, which has been marked
WONTFIX now, so "X on tab" is a no go, for all the reasons listed in that bug.

My current vote goes to attachment 90335 [details] (combination space & mouseover), with
maybe some discussion on reducing redundancy (like maybe the drawer only shows
up for non-active tabs).
Brian:
You might want to try it for more than a few minutes.  I've been using it for
weeks and have never accidentally closed a tab.  On the other hand I have
managed to click Mozilla's stationary 'X' twice, accidentally closing an extra tab.

I opened this bug because I didn't think an X on the tab was a great idea.  I've
changed my mind after seeing Multizilla's mouse-over, but still think this bug
is a good idea if Mozilla is not going that way.  I like attachment 90334 [details].

BTW, I too was unhappy about the Multizilla install process.  I have since
figured out some manual tricks to avoid the same nonsense everytime I download a
new Moz nightly.
Can I suggest that you guys have a play with http://eclipse.org/'s
implementation of tabs? They only show an X on the currently displayed tab, but
one will appear on other tabs on mouse rollover. 

My problem with having the Close button on the far right is that it is too easy
to mis-associate the close app close button with closing the tab (which I just
did). In eclipse the close button is much more tightly integrated with the tab
itself (by being on the tab) thus making the association much tighter...
I second comment #26: the way 'show close button on mouseover' behaviour is
implemented in Eclipse IDE, which I've been using extensively for about nine
months now, works great and I really wish Mozilla would do something similar.
(Not to mention that closing an active tab should take me to the last active,
not the left neighbour., but that's a different bug.) As for the concerns that
it makes it easy to accidentally close a tab, I can honestly say that I've
*never*, ever closed an Eclipse editor because the close button appeared just as
I hovered over the tab to select it. If the close button always appears in the
same place (say right edge of the tab), and you ensure that the tabs don't get
too small (again, Eclipse solves this quite nicely), this just is not a problem.
I think we have enough examples. What we need is someone who is willing to put 
one to work. From what I can tell, this should only require some XUL hacking 
and would be a good starter project for someone who wanted to learn to hack 
the Mozilla chrome. Any takers? Anyone with experience in 
HTML/XML/Javascript/CSS can probably do this.

Here is a doc to help anyone get started with the XUL hacking: 
http://www.mozilla.org/catalog/architecture/xul/

These docs, located on the first page of www.mozilla.org will help you get 
started on creating the patch file...
http://www.mozilla.org/hacking/
http://www.mozilla.org/source.html
http://www.mozilla.org/build/

If you want to just edit the XUL contained in the JAR file and submit the file 
here, someone could probably create the patch for you, but it saves time to be 
self-reliant in the projects.

Personally, I like http://bugzilla.mozilla.org/attachment.cgi?
id=90334&action=view
Keywords: helpwanted
Brian: 

After looking at attachment 90236 [details], I would have to say I like it better. I
didn't look at it before because it was striked out. I think that putting the
controls in one spot will make the X stand out less. I don't want the X next to
the "New Tab" because accidental closing might occur. If we ever want to add
more buttons, they can be placed on the left with the "New Tab" button.

I agree with Jeremy that the "New Tab" button is a bit off, could it just be
moved down a bit and the line removed?
The reason I opened this bug was because the existing 'X' is not clearly
associated with the object of its action; specifically the current tabbed page.
 I think attachment 90236 [details] does a good job of fixing that and attachment 94293 [details] is
a nice improvement on that.  Putting the 'New Tab' button in the same area would
be counter to that association, as the object of that button's action is not the
current tab but more nearly the empty area of the tab field.
I like this idea. It's a shame the "tab" containing the close button looks
different from the browser tabs, though perhaps we should make the browser tabs
look more like it. Marlon, you had some ideas in this area?
Just change the not-used bookmark icon to the left of the tab title to be the X,
with mouse-over effects. Having a tab title anf the X on the oppisite side of
the browser window is poor GUI design. One could also argue that having the X on
the left hand side is equally poor, but win3.1 users (and indeed 95 supports it
too) know you can close a window by the icon to the left of the app (or
window's) title. Plus the X shoul dbe obvious enough.

Associate (by position) the X with the tab, by having it actually in the tab.
The proposed idea of the X in t's own tab and  connected to that windows tab is
visually more complex than it has to be. Also having X buttons on each tab
allows for tabs to be closed without having to bring them to the foreground.
Attachment #97478 - Attachment description: X is in Tabs → X is in Tabs. Ignore the erroneuous X under the URL. I didn't see that until after I posted it.
Jason, your idea has been discussed in bug 108938 and (unfortunately, because
that's what I want, too) discarded.
>Jason, your idea has been discussed in bug 108938 and (unfortunately, because
>that's what I want, too) discarded.

This is my preference as well.  That is why I use MultiZilla now.
http://multizilla.mozdev.org/
MPT: What is your opinion on this UI issue?
Hi,

I like <a
href=http://bugzilla.mozilla.org/attachment.cgi?id=90236&action=view>90236</a>
also. 

Please note, this bug is really making the assumption of staying with one global
close tab button. <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=108938">Bug 108938</a> has
discussed putting one button per tab to death - please reopen that if you want
to  discuss that. 

To answer some of the objections:
- doesn't look like a tab. 
That's because it IS NOT a tab. It is part of the window, only to save vertical
space it's shifted up. Therefore it is important to make it look like an
extension of the window.

- it's not associated with the tab. 
That's true, but on the other hand it is clearly associated with "what I am
looking at now" (i.e this tab), in the same way as the main window close button is.

I don't know about other operating systems, but OS/2 and Windows both have a
close button in that approximate position, when using multiple windows (MDI)
maximized. So there is a strong existing association. 

Another great reason not to put it on the tab is that then the "close this tab"
is in a different place all the time. i.e "muscle memory".

And yet another, is that tabs have strong existing conventions. Clicking a tab,
selects it - and that's it. Putting controls *within* tabs seems like a really
bad idea, GUI wise. Whatever appears on the tab should be information only,
telling you what is on that tab, not actions.

- tab controls should go together
Maybe. But the risk of accidentally clicking the wrong one seems high. Also,
that then associates "new tab" with this window, which it has nothing to do with!

I actually really like the way it is now. It's visually attractive and logical.
Left hand - new  - right hand - close. 

- can't close a tab that's not current
But that's exactly the kind of thing a context menu is for. Newbies can go to
the tab then click close. When they get a bit more advanced they might learn
about some shortcuts, like keyboard or context menu.

In summary, please remember that we aren't designing in a vacuum. People have
expectations, there are strong conventions that you shouldn't break without a
very good reason (and no, your minor personal convenience is not a reason).
QA Contact: sairuh → pmac
I personally vote too for the Eclipse-like solution.

And for those who say that the close button on the tab can make one close tabs
accidentally, let me add a bit of blasphemy: how about a "tab close undo" button
that would sit near the "Open new tab"? It would also help those that close a
tab and regret it immediately afterwards (happened to me on several occasions).

.......

Let me describe my personal experience. I often open a lot of links from some
page , then view them all one-by-one, and close those that are unnecessary. I
can live with the context menu, but I find myself constantly using the rightmost
X button, which is definitely too far away. And after each close I have to
search back the tab I was last using.

To those that say "OK, so you can use the context menu", I can just answer:
Hell, it is *NOT CONVENIENT*, it is *SLOW*. I know myself to be able to get used
to many kinds of GUI, those more or less intuitive, and my brain just refuses to
take this context menu!
Blocks: 188583
I am in favor of placing the close button within the tab itself (see
attachment). I don't know Eclipse, but I like the way they did it in NetBeans:
small close buttons on the right side in each tab.

I hope my comment will give this stale bug a stir. I think it should be
addressed to make tabbed browsing an even better experience.
Don't waste your time asking for "close button within the tab itself", Bug
108938 has been marked WONTFIX a long time ago, and rightly so. We shouldn't
give up precious screen real-estate for multiple close buttons. 

IMHO, Mozilla's tab implementation is by far the best in any browser, including
Phoenix/Firebird and definitely better than the poor tab implementation in
Safari (black text on dark gray?!?)

Prog.
Actually, it's not the dark gray background that makes Safari tabs so 
illegible, it's the *brushed metal* dark gray background. Mozilla's default 
color scheme is not that different, but it is undoubtedly more legible.

Prog.
Please make the background color of the X stay the same as 
the background color of the page (or the active tab)
This would be more effective if the active tab color 
was distiguishable from the inactive tab color.
Blocks: 128632
The Safari-way is probably going to win this one :-(

https://bugzilla.mozilla.org/show_bug.cgi?id=108938#c123

Google deems it to be more "usable".

Prog.
Kevin, does the implimentation in the current firefox trunk build satisfy your request? (see below)


(In reply to comment #42)
> Don't waste your time asking for "close button within the tab itself", Bug
> 108938 has been marked WONTFIX a long time ago, and rightly so. We shouldn't
> give up precious screen real-estate for multiple close buttons. 

Well, with Bug 308396 comment 14 it is back :)
Indeed, this is fixed.  The X is now on the tab.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Core product designation for this bug is misleading as the 4/19 build of SeaMonkey does NOT seem to include this functionality.  Personally, I'd rather not have it - so, as an individual, I'm not complaining - but in terms of an objective assessment this shouldn't be treated as a "core" patch if it doesn't apply to SeaMonkey... (Unless there's something else here that I'm not following.)
Jason is technically correct.  However, this bug predates Firefox - wow, I can't believe it's been 4 years - and IIRC, 'Core' was not a product choice when I opened it.  That was assigned after the Bugzilla reorg.  Being an interface issue I would have expected it to be assigned to either Firefox or Suite.  Since I have followed the route to Firefox, this bug is fixed for me.  If anyone cares about having it in Seamonkey they are welcome to open another bug or reopen this one and set the product to Suite.
(In reply to comment #47)
> Indeed, this is fixed.  The X is now on the tab.

Reopening as it's written against suite and it's not fixed.  Sorry I mislead you

(and, if this was for FF and it was fixed, it would be more appropriate to dup this against the fixing bug rather than mark THIS bug fixed)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Improve visual association of 'X' close button with current tab → Improve visual association of 'X' close button with current tab (suite)
(In reply to comment #50)
> (In reply to comment #47)
> > Indeed, this is fixed.  The X is now on the tab.
> 
> Reopening as it's written against suite and it's not fixed.  Sorry I mislead
> you

But wouldn't it make sense to change Product to Mozilla Application Suite if this bug is now SeaMonkey-only?
The reporter doesn't use SeaMonkey and doesn't care about this at all.  Surely there's a way to kill this.  I'd be happy to have it changed to Firefox and duped against another bug.
Not appropriate to mod to firefox as the comments here are in the context of suite and still valid there (i.e. suite could use an improvement), whereas FF has moved on with it's own UI standards and owners.  It would also not be appropriate to dupe to bug 108938 because this bug was deliberately left open - bug 108938 comment 87 - after it was wontfixed.


(In reply to comment #51)
> But wouldn't it make sense to change Product to Mozilla Application Suite if
> this bug is now SeaMonkey-only?
 
Robert might know - will this shake out in the planned components reorganisation?
http://www.gerv.net/temp/bmo-reorg.html says this component will just move to SeaMonkey, yes. But please don't CC me for any bug where you find unclarities, I'm overworked enough as-is already.
I agree with the feature request. I also have to think twice before closing a tab to see if the tab I'm closing is active. I suggest adding the [x] inside the tab itself. If you really want to save space, include the [x] only in the active tab and remove it when the tab is in the background, this way you have only one [x] always.
Today it's been exactly 6 years that the original author did this feature request, backed by a number of other users to make it easier and more straight-forward to close tabs, binding the "Close" button to the active tab itself. Will this feature be implemented? Thanks.
Product: Core → SeaMonkey
Assignee: hyatt → nobody
Status: REOPENED → NEW
QA Contact: pmac → tabbed-browser
Target Milestone: Future → ---
Importance: Normal. Seamonkey 2 currently obeys browser.tabs.closeButtons only
for tabs in MailNews. http://kb.mozillazine.org/Browser.tabs.closeButtons
Severity: enhancement → normal
Whiteboard: Make browser.tabs.closeButtons work
Duping this bug for clarity. The discussion was broad, the decision from Bug 108938 was changed and most comments are eight years old. 

Work for SM goes on in new bug. Voters are encouraged to move their votes.
Status: NEW → RESOLVED
Closed: 18 years ago → 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: