are non-selected tab (hover and not hovered) background images different enough? spun off from bug #350139 screen shot coming.

fixing this would involve new images from jay.

While the difference between hover and non-hover is not exactly stark, but its not too bad. Its very similar to the hover effect on navigation toolbar buttons in terms of the difference. I don't think this is too critical.

Looking at the original comment and Comment #1, it seems this is still too close. Thanks for all your work on improving this, Seth. I've been observing, and not commenting, as your fixes come in right after the issues show up.

I wonder if there should be a hover effect. The target is so big, that you can't miss it. I once had a hover effect on my tabs, but I took it away.

--> me for a decision; currently considering using the active state image instead (which would also solve bug 350687).

One possible suggestions to help differentiate between the hovered and not-hovered tab would be to return the lower opacity text and favicon on the non-selected tab (just the text and favicon opacity, not the tab image set). On the hovered state, you can then return the text and favicon to full opacity. With the slight background change, the opacity of the tab contents changing to full, and the understanding that the user has hovered over the tab to get to this state, this would probably be more than enough to differentiate visually to the user that the tab is hovered. There is more than enough of a difference between the hovered tab background and the selected tab background to avoid confusion between these two states. You also might think about changing the tab close box to full red on tab hover to further differentiate between hovered and non-hovered. This would also eliminate the visual cue on tab hover that the close box is disabled.

Not a blocker, but if Jay's tweaking these images anyway to make them semitransparent (which I think he is in bug 350690) we should be able to make the hover state a *bit* lighter. I'll leave this up to him to dupe or prioritize.

This bug has now been fixed in RC2 and should be closed.

> This bug has now been fixed in RC2 and should be closed. yes, this bug is fixed. thanks wayne. note: I have seen some comments in mozilla.dev.apps.firefox that what we did was not enough. http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/54b2b598927eb3ba/ec744312c75abbd4#ec744312c75abbd4 so perhaps this is an open usability question, cc'ing Alex in case this is already on his radar.