109607 - can't tell which tab in classic has focus

Status: RESOLVED WORKSFORME

(SeaMonkey :: Themes, defect, P5)

Description

[K Chayka]

win32 build 1109

In Modern, the currently focused tab is obvious at a glance by it's color.
In Classic, it's impossible to tell at a glance which tab currently has focus -
they're all the same lovely shade of gray and there is no distinction in the
border or text color.  More than once I've dragged a link to the currently
focused tab by mistake.  Pretty darned annoying.

Suggestions for focused tab:
- use a different background color
- use a different text and border color
- use a different icon

I'm not particularly fond of the icons idea, I'd rather they weren't there at
all.  They take up too much space at smaller window sizes with a sufficient
number of open tabs.  But since they were added, they are the only way to
quickly tell where one tab ends and another begins.

Comment 1

[Pavel Roskin]

This problem is not OS-specific.  I observed it on Linux as well.  I agree that
it's a serious problem and needs to be fixed.  I suggest black border like the
one that surrounds toolbar buttons when the mouse is over them - two pixels on
the right and one pixel on the top and left.

Comment 2

[K Chayka]

I think a 1px black border might not be enough, at least on Windows.  Some other
color, like red or blue would be better.  Using a different text color in
addition to border would be good, too.  See attached screen shot.  A pic says a
bunch of words, and all that...

Comment 3

[K Chayka]

Attachment: guess which tab has focus

Comment 4

[Thorsten Konetzko]

Attachment: Tabs with classic theme / default windows color theme

Might be a prob with the OS-color theme (windows color theme in this case).

A user who selects colors with little or no contrast surely can't tell the tabs
from another, but I don't think this is a mozilla problem.

Comment 5

[K Chayka]

I disagree about it not being a mozilla problem.  Tabs and the Toolbars both
appear to use the Windows 3D Object for its colors.  In Windows Appearance
settings, there is no control over 3D Object border colors.  Like just about
everything else, Windows decides what color it thinks is appropriate.  With
lighter colors, they all blend into each other and the Tab border is virtually
invisible, particularly with a high screen resolution (mine is 1280x1024, 96dpi,
17-in monitor).  If I change the 3D Object to a dark color, like navy, the
borders are much more visible, but I don't plan to change my whole Windows color
scheme because of one app.  It's pretty silly to say it's the user's fault for
using a particular color scheme.  It doesn't cause a problem with any other app.

In Modern, the active tab gets a background color change, so it's a no-brainer
to determine which one it is.  Classic needs something besides a couple pixels
difference in height.  It alone isn't enough to distinguish the active Tab.

Comment 6

[Hakon]

Maybe this is out of subject but,
I also think that the tabs are too wide.
Before they were no wider than it's caption, and that was better because it's 
slightly faster and more convenient to switch between the tabs, the more narrow 
they are.

Comment 7

[Jeremy M. Dolan]

Wouldn't it be a quick one liner to simply make the de-selected tab a tad darker
shade? Very often it's incredibly difficult to figure out which tab you're on in
classic. I think this is masking some tab focus issues as well. (Some times it
seems the wrong tab in the tab bar is selected, but it could be my eyes bugging
out looking for tha tslightly differant ridge.)

Suggest this is resummarized to specifically address this particular issue
(currently quite vague), and nominating for 1.0.

Comment 8

[K Chayka]

IMO, the problem is caused by using just system ThreeD colors for tabs in
Classic.  Resorting to userChrome.css changes to work around this is doable, but
pretty darned unintuitive.  I suggest that the selected tab use Highlight colors
as a default instead of ThreeD colors:

tabs > tab[selected="true"]  {
  background-color: Highlight;
  color: HighlightText !important;
}

This works quite well in all of the Windows predefined color schemes, and will
probably work better as a default in a custom color scheme, too.  How about *nix
and Mac?

Comment 9

[John Morrison]

-> themes

Comment 10

[Joe Hewitt (gone)]

-> shliang

Comment 11

[Hakon]

Voting for comment #7.
See Galeon (1.0) for how they have fixed this.
Couldn't this be fixed sooner than 1.1?

Comment 12

[Jeremy M. Dolan]

Resummarizing as there were no objections. I tryed the CSS in comment #8, this
makes the active tab a dark blue background with grey text. Quite ugly and
distracting. My suggestion in comment #7 stands (and was seconded by Hakon).

Comment 13

[Jeremy M. Dolan]

I should also mention, the blue background from that CSS also makes page icons
eaither ugly or very hard to see.

Comment 14

[Hakon]

This also applies to the tabs in Page/Frame Info.

Comment 15

[shliang]

the tabs look like the windows native tabs so they are not getting changed. we
can't make the unselected tab a little darker because there is no appropriate
system color. 

Comment 16

[Jeremy M. Dolan]

No platform has an unfocused color? Mac? Win? Gtk? I find that hard to believe,
but if that's the case, I'll file a seperate bug for a mode for Classic where
system colors aren't used.

Comment 17

[R.K.Aa.]

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

Comment 18

[Jeremy M. Dolan]

Reopening to find *some* solution.

What about bolding the text? The "Lo-Fi" theme does this. Not quite as
attractive as shading, but it's safe.

http://xulplanet.com/downloads/view.cgi?category=skins&view=lo-ficlassic

Comment 19

[shliang]

i tried that before (bolding the text) and i agree it does look better, but i
decided against putting it in because windows tabs don't do that. 

Comment 20

[Jeremy M. Dolan]

What's a "Windows tab" and what DO they do?

Comment 21

[Sören 'Chucker' Kuklau (gone)]

Jeremy: He probably means Taskbar task items. They work in a similar way. An
active item has a light background, a different 3d effect, and bold text. All
others have a darker one and normal text.

shliang: Hmm... my Windows does it, unless we're talking about different things.

Comment 22

[K Chayka]

I agree that bolding the text on the active tab is probably a good, safe
solution.  Windows does indeed do this on its taskbar.  The focused task also
gets background and border changes, which appear to be the same as scrollbar
styling (which isn't configurable, at least not on all Win versions).  That
extra styling would be nice, but not absolutely necessary, IMO.

I vote for bolded text.

Comment 23

[Michael Wardle]

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

Comment 24

[Andreas Kunz]

When shading, bolding etc. are not allowed because non-standard, what about the
tab icon?
Many or most (at least: Windows-) applications don't even have tab icons, so why
not surround the one of the active tab with a glow or something (I suppose
changing of the icon's coler itself would be to difficult)?

Or better: replace the icon of the active tab only by a dedicated "active" icon?
This way all the other icons still present their information while the icon of
the active tab is still present and visible in the URLbar.

I really often do not know which tab is active and close the wrong one by
mistake, which makes me crawl through the history to get that page back.

By the way: how does Opera handle this?

Right now Classic Mozilla's usability for me is clearly limited by a feature
that makes it look more standard-like. I'm not quite sure if perhaps the
standard is wrong - or at least didn't take into account suchlike use of tabs...

And: Mozilla menu items (File, View,...) look raised when hovered over and
pressed when pressed, while standard Win95 applications show no reaction on
hovering over and change the colour on pressing the mouse button.
- Standard behaviour?!?

Comment 25

[Sören 'Chucker' Kuklau (gone)]

Attachment: screenshot of Opera 6.02 tab view

> By the way: how does Opera handle this?

Like this.

Comment 26

[Sören 'Chucker' Kuklau (gone)]

In Opera 6, hovered tabs are slightly lighter, and active tabs have bold tags
and are embossed.

Comment 27

[Andreas Kunz]

Attachment: Screenshot - almost impossible to find the active tab

Ok, now compare this screenshot with the one of Opera:
you have three seconds to find out which tab has the focus.
Time's up! You lost.

Because of the better speed compared to multiple windows my screen often looks
like this and I think it is safe to state that it does not look very usable.

One more proposal: the only difference else than that the active tab is
minimally higher, is the bottom of the tabs: the active one is joined with the
rest of the window, the others are visually separated by a thin light line.
Might it be possible to make this line more visible? Broader? Lighter?
Unfortunately a shadow seems not to be possible for that task, because shadows
fall to the lower right...

Comment 28

[K Chayka]

> Might it be possible to make this line more visible? Broader? Lighter?

Broader, maybe.  Lighter, no.  The tab colors are determined by your desktop
theme, which may be a light background with dark foreground or the other way
around.  The contrasting border colors could be light or dark.  With my custom
Windows desktop, the border is almost indistinguishable from the tab background,
so widening it a pixel or two wouldn't really help.  With some Linux Gnome
themes, the borders can't be seen at all.  Who knows about Mac...

Bolding text on the active tab is the only suggestion I've seen so far that
could really be considered a one-size-fits-all solution.

Comment 29

[Andreas Kunz]

Another idea: 
Tab activation mainly causes the tab getting 1 or 2 pixels higher, which is
almost invisible because 
1) the border is only 1 px thin and 
2) Tabs have the same colour as the background "behind" the tabs (at least on my
computer and in all attachments). 

If the colour of the tab background was quite different, I'm sure that the
difference in height would be much more visible (not visible, where exactly the
thin upper tab edge is, but very visible if the differently coloured background
above is e.g. only 1 pixel high instead of 3 pixel or so). 
This should make identifying the active tab easier.

Another glitch: shouldn't be the background visually be "behind" the Mozilla
window border (by a light vertical line on the right of the "close tab" button)
on the right side as it is on the left (indicated by the shadow left of the tabs
thrown by the Mozilla wondow border). And why is the thin bar below the tabs but
above the html display area separated from the left browser window border by a
shadow ("lower"), but on the same visual heigt with the right browser window
border? But if at all, that is another bug... 

Comment 30

[K Chayka]

Attachment: proposed css changes for Classic

The attached css gives up to 3 visual clues as to the active tab:

1.  A contrasting color to the tab strip background (thanks for the idea,
Andreas!).  This makes the height difference of the active tab much more
noticeable, especially with themes that have a low contrast between tab
background and border colors.  The active tab height was increased by 1px to
improve this distinction, too.

2.  A different color (Scrollbar) for the background of the active tab.  With
some desktop themes, this won't be any different than inactive tabs, but for
those that use a different color, it will be noticeable.  It's usually a shade
darker or lighter than the inactive tab color.

3.  Bolded text for the active tab.  If neither #1 or #2 make a noticeable
difference, this is probably the best that can be done.

I tested this with all the pre-defined Windows themes and my custom one, as
well as all the pre-installed Gnome themes on Mandrake 8.1 (it was a lot!). 
It's invariably better than the current non-styles, plus it is more in tune
with the styling of both the Windows and Linux/Gnome task bars.  Will attach a
few screen shots showing the effects.  I don't have access to a Mac, so I can't
test that.

Anybody wants to try it, just append the attached file to your userChrome.css.

Comment 31

[K Chayka]

Attachment: screenshot of Windows default theme with proposed css changes

Comment 32

[K Chayka]

Attachment: screenshot of Windows Rainy Day theme with proposed css changes

Comment 33

[K Chayka]

Attachment: screenshot of Gnome default theme with proposed css changes

Comment 34

[K Chayka]

Attachment: screenshot of Gnome Tshell theme with proposed css changes

Comment 35

[Jeremy M. Dolan]

K Chayka's proposed CSS looks quite nice. Definately an improvement. It's a bit
tacky to have to use scrollbar color for a nonscrollbar element, but we don't
have much choice. This is sorely needed, and it looks great with GNOME and
Windows default themes. Only one problem... is the scrollbar color garanteed to
be a readable background for text?

Comment 36

[K Chayka]

Both Windows and Gnome use Scrollbar color for the active task in the taskbar,
so I followed suit. :)

Out of all the available CSS2 system colors, only Scrollbar has any consistency
to it, as related to the inactive tab background.  There will likely be some
desktop themes that have an unusual Scrollbar color that won't lend itself well
to this task, but in testing all those Linux themes, they were few and far
between.  In general, they looked bad in Classic overall so I'd suspect those
folks are probably using some other mozilla theme.  With a custom theme, nothing
can be guaranteed, but it looks good with mine. :)

BTW, the text on the active tab also appears in the window title bar, so it's
never completely hidden.  With the limited amount of text on tabs, that's
probably where you're going to look anyway, especially if you have a lot of tabs
open. ;)

Comment 37

[Andreas Kunz]

I think K Chayka's proposal is generally nice.
But the things I do not like too much are:
The close-tab button to the right does not look very button-like at all, having
this dark colour. Could this button somehow get the same colour as the tabs?
(ThreeD or something)
And - best visible in the Windows Rainy Day theme attachment (and also in the
customary theme I use): the thin horizontal bar below all the tabs has the same
colour as the active tab (in most cases now lighter than regular ThreeD items).
That looks not very logical. I think it is in fact not really the bar's colour,
but the bottom of the inactive tabs ("border-bottom").
The "padding-bottom", which initially was supposed to look like the part between
tabs and html window, is set to 0px, which I don't like too much - on the other
hand I have the impression that it gets the same colour as the background behind
the tabs, which would make it look dark - again not very logical as I would
expect it to have the same colour as the border of the Mozilla application window...

In short: dark background looks very good, I also like the bolded text after
working with it for a while.
But a lightened active tab looks a bit strange. Why another colour than
comparable (top-level) elements??
If the tabs should have different colours (I now don't think so anymore), then
the INactive should get darker somehow (only question: how?)...

Comment 38

[K Chayka]

Andreas, whether the active tab gets lighter or darker (or changes color at all,
for that matter) depends entirely on your desktop theme.  There is no way to
predetermine which way it will go, and change the coloring of inactive tabs in
some cases and the active tab in others.  Sorry.

I attempted to do something about the close button.  I wasn't very pleased with
the looks of a background color and attempted to apply a border so it would look
more button-like, but can't seem to find the right class(es) to apply this. 
Adding a border property to the tabs-closebutton class in browser.css has no
effect.  I've searched through various xul files looking for clues, but have
come up empty.  I'll add the background color for now, same color as inactive tabs.

BTW, if you don't like the looks of the horizontal lines, feel free to edit the
attachment to your liking and post the results here.  I'd rather you made the
revisions yourself instead of me guessing what you have in mind.  Be sure you
test the change in more than one desktop theme.  What you think looks good in
your own preferred theme may not be so hot in others, plus the changes have to
be generic.  That is, no hard-coded color values.

Comment 39

[K Chayka]

Attachment: added close button background to proposed css changes

Comment 40

[Andreas Kunz]

> Andreas, whether the active tab gets lighter or darker depends entirely 
> on your desktop theme.

Of course. What I wanted to say is: the active tab should - in my opinion - have
the same colour as other foreground elements such as the toolbar or the
application window borders. Only the inactive tabs might be coloured different
(and it while it seems not to be possible to make this sure, it still certainly
would look better if they were darker, because they are in the background).

The button already looks much better; if only there was a border while not
hovering over...

> BTW, if you don't like the looks of the horizontal lines, feel free to 
> edit the attachment to your liking and post the results here.

Of course I began doing so, but since I had no knowledge about modifying the
Mozilla UI until a few hours ago, this was only partly successful. And because I
do not have much time during the next weeks, I will try to contact you per
e-mail to avoid spamming people here with lots of screenshots.

Comment 41

[K Chayka]

Attachment: more polish to the proposed css changes

I figured out that the problem with button borders wasn't the class, but the
property (it needs -moz-border, duh).  I changed the close button background
color to a hover effect.  There are too many themes that don't have a unique
Scrollbar color to use that as a hover effect, and hover feedback really is
needed.  I think I cleaned up the colors in the unused left/right areas of the
tab strip, too, so there's better continuity across the window.

It looks pretty spiffy in the Gnome thEmacs theme. :)  I just wish there was
something to be done about the close [x] graphic.  It's black in all themes, so
it's invisible in dark themes, of which there are many in Gnome.

Does anybody have access to a Mac (or OS/2 or any other platform) to test this
stuff?

Comment 42

[Lars Linek]

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

Comment 43

[Andreas Kunz]

Attachment: css changes to better distinguish the active tab

These proposed css changes do the following three things that should make it
easier to find the active tab (based on one of K Chayka's css files):

1) Different tab background color (as proposed before): Here I used the same
color as the sidebar top (which is located just to the left of the tabs, which
fits nicely). So the tab close button now looks and behaves exactly as the
sidebar close button (-> consistency).

2) Lower inactive tabs: I increased the difference in height between the active
and the inactive tabs by one pixel. The dark background from above adds to this
effect. Windows (at least) standard tabs (e.g. see TweakUI) are lower than
Mozilla ones, so with higher tabs a higher difference should be allowed, I
suppose.

3) Bold text on active tab: this has already been discussed and in fact does
help a lot. If it  really is considered too non-standard and keeps the other
two from being applied, then leave it...


An additional fix that has not really to do with this bug:
- the right border of the tabbox has no 3-D look as the left one. Changed that
by adding a vertical lighted border.

All these changes can be seen in the following attachment.
(or by saving this css file as userChrome.css in your profile's chrome
directory and restarting Mozilla)


Well, I decided against a different color for the active tab because all
foreground UI elements should have the same color IMHO.
And I see no reason why the active tab should get more attention than e.g. the
"Back" button (and therefore be put in the foreground by making it lighter).
Modern theme may do that, but that theme is more colorful, anyway.
Light tabs do not look very Classic, I think.

I still like the idea of the INactive tabs getting slightly shaded (to make
them step in the background), but since there is no dedicated predefined color
for that one can never tell what an arbitrary one will look like in different
desktop themes, I'd rather not vote for it.

Comment 44

[Andreas Kunz]

Attachment: Comparison of my last proposal to good ol' Classic theme

In this screenshot my proposed css changes from my last comment are applied,
described and compared directly to Classic theme as it was before, so you can
make yourself a picture of usability improvement.

Comment 45

[R.K.Aa.]

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

Comment 46

[Matthew T (active 1999-2002)]

> Does anybody have access to a Mac

Whatever you do, do not change Mac Classic when fixing this bug. So don't change
navigator.css, unless you split it into Windows-/Mac-specific files first. (That
needs to happen anyway, to fix other platform-specific Classic bugs.)

This is a bug in the default appearance of *Windows* tabs -- Mac native tabs,
and the Mac Classic tabs which imitate them, have always used a lighter color
for the active tab, and so do not suffer from this bug. Raising tabs, using the
scrollbar color (dark gray), and boldening the system font would all look
extremely ugly on Mac OS.

Comment 47

[guanxi]

Confirming on 1.1b (2002072204) on Win2k

Comment 48

[guanxi]

In a tracking bug, Shark Daddy says this bug doesn't affect "most systems", and
may be caused by "a 3rd party app".  Can anyone confirm/deny?

His comment:
http://bugzilla.mozilla.org/show_bug.cgi?id=92997#c67

Comment 49

[Andreas Kunz]

To comment #48: this bug is about all the tabs plus their background having the
same colour (the active tab only being distinguished by being *slightly* higher
and wider), which is standard behaviour on at least Windows (I think on Linux,
too) and makes finding the active tab difficult. This should have been clear
from the bug's description, shouldn't it?
It doesn't have anything to do with "3rd party apps".

Shark Daddy might be right when he said it looks "normal", only: this normal
look is the one that is not helpful for finding the active tab and this bug is
about changing the normal look.

Comment 50

[Shark Daddy (Jonathan L.)]

Attachment: Normal.

The Classic Theme is designed to emulate to a large extent a Windows
environment on a Windows platform. Deviation from this needs a really good
reason and a really good fix.

This is how it looks in Mozilla on my (Win98) system, and how it is supposed to
look. The active tab is clearly visible, and pretty much (not exactly, but
nearly) conforms to Windows standard tabs (also shown).

Comment 51

[guanxi]

Shark Daddy - Thanks for contributing the screen shot.


From your comment in bug 92997:
"on most systems it doesn't look like that (i.e. it looks normal). It came as a
result of some 3rd-party app"

Are there differences between your screenshot and the one that comment refers
to, besides fewer tabs?:
http://bugzilla.mozilla.org/attachment.cgi?id=94250&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=78182&action=view

 * * *

"The active tab is clearly visible"

Picking 1 active tab from 5 works adequately for me, too.  It narrows down the
problem a bit.  How does it look with 8 (where I start having trouble) or 15 tabs?

 * * *

"The Classic Theme is designed to emulate to a large extent a Windows
environment on a Windows platform. Deviation from this needs a really good
reason and a really good fix."


The question is, what is more important, A) the users' experience, or  B) the
Windows GUI standard for tab fonts and background colors?  My take on it:

A) Moz exists for users.  It's an Application used by people to interact with
websites; it's not an OS, like Linux.  GUI should be a very high priority,
unless Moz provides only the XUL tools and GUI is someone else's problem.

B) Standards are very useful tools.  I support sticking closely to W3C standards
because it helps Moz integrate with many many web pages, servers, etc.  I see
little benefit to being so religious about the Windows standard for tab fonts
and background colors -- there is certainly no integration issue.  Andreas'
change will be close enough that it will seem familliar to users.

Comment 52

[Daniel Wang]

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

Comment 53

[Robert Wall]

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

Comment 54

[Chris Casciano]

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

Comment 55

[Jason Bassford]

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

Comment 56

[Karsten Düsterloh]

WFM on Mac OSX, Win2k and Linux with current SeaMonkey 1.0b builds.