New tab icon image does not change on hover, only on selection

RESOLVED WONTFIX

Status

()

Firefox
Theme
RESOLVED WONTFIX
9 years ago
8 years ago

People

(Reporter: u88484, Unassigned)

Tracking

({polish})

Trunk
x86
Windows Vista
polish
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3.5 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
The new tab icon image does not turn blue on hover, it only turns blue on selection of the button.
Flags: blocking-firefox3.5?
(Reporter)

Updated

9 years ago
Keywords: regression
It's not supposed to turn blue on hover.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

9 years ago
So it is supposed to always look disabled and only change colors when you click the button?  That does not sound right at all...especially the changing of color on selection only.  The new tab button was added to get more exposure to tabbed browsing and now the first release with the button is supposed to have the button looking disabled at all times.  That makes no sense at all.
Well I think you are both correct here, sort of.

I see the point about it looking disabled, but this has little to do with the hover state.

The real issue is that with the Windows default theme both the new tab and list all tabs buttons have the look of being disabled in the non-selected, non-hover state even though they are really active

I would venture to say that this is just wrong, or at least inconsistent with the rest of the Firefox UI.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
File a new bug, then? The fact that the icon does not change the color on hover is intentional.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → WONTFIX
I filed Bug 495631.
(Reporter)

Comment 6

9 years ago
(In reply to comment #4)
> File a new bug, then? The fact that the icon does not change the color on hover
> is intentional.

Based on what?  The patch not having the css to change the image on hover?  I don't see anywhere in bug 494658 or bug 488439 about it being intentional.

I'd like to hear what Alex has to say on this instead of just closing this bug without discussion.  There is no point in only changing the image on the hit state, the flash of color looks like a bug in itself.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I imagine it's based on the fact that it's never changed colour on hover since we implemented it, and it's not specifically mentioned as a requirement in bug 494658.

Anyway, not blocking, but yes, Alex should chime in to ensure this was his intent. Renominate if it wasn't.
Flags: blocking-firefox3.5? → blocking-firefox3.5-
Keywords: regression → uiwanted
Well, for parity, the New Tab Button on IE8 /Vista64  HP SP2 turns 'blue' on Hover.
(In reply to comment #6)
> There is no point in only changing the image on the hit
> state, the flash of color looks like a bug in itself.

A separate one, as well.
>Alex should chime in to ensure this was his intent

The hover effect is achieved with a change in the button itself (dao's cool animation).  Vista tends not to use any toolbar icon hover effects, and XP's hover effect is a color change which doesn't really work here given that we are starting with a monochrome etch.  In regards to this not looking fisher price enough, that was a very intentional aesthetic decision and reviewed by Dao and Beltzner in email before we started landing the icons.

The glowing hit state is intended to make the moment of action more dynamic.  This is something we are doing cross platform.
My .02:

Vista uses _clear_ visual effects on all buttons, especially those that are "high-profile". Take for example the Windows Explorer, the refresh button, Folders button, and all others that I am aware of have a highly discoverable hover effect. In IE 8/7 the new tab button *gets* the icon only on hover. IMHO this change should first bake on trunk, with appropriate modifications made to the background effect first, before landing on branch. I was very surprised when I rebuilt branch today... (admittedly some of the branched off bugs would definitely help, maybe even make this moot, but will those bugs land on branch as well?)
Status: REOPENED → NEW
> IMHO
> this change should first bake on trunk, with appropriate modifications made to
> the background effect first, before landing on branch. I was very surprised
> when I rebuilt branch today...

Which change? The new tab icon itself never had a hover state, only the button.

> (admittedly some of the branched off bugs would
> definitely help, maybe even make this moot, but will those bugs land on branch
> as well?)

Which bugs are you referring to?
(In reply to comment #12)
> Which change? The new tab icon itself never had a hover state, only the button.

Right, but the hover effect of the button used to be much more discoverable.

> Which bugs are you referring to?

For now, bug 495668, bug 495631 and this bug are all that I am aware of.
The Scrollbar and the 'End-caps' change to 'blue' on Hover, are they going to change also?  I see no logic in not having the 'New Tab' and 'All Tabs' change on Hover also to match the scroll-bar and end-cap arrows. 

Also, I have noted there is no hover effect of any kind in the Search-box in reference to the drop-arrow or the 'search-glass' icons.  

People are not going to click on something to 'see what this does'. 

Its already been noted in today's build forum that the change is maybe too drastic. 

http://forums.mozillazine.org/viewtopic.php?f=23&t=1274525

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago8 years ago
Keywords: uiwanted
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.