Closed Bug 391928 Opened 13 years ago Closed 12 years ago

Feedback required when hovering over DM UI elements

Categories

(Toolkit :: Downloads API, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: stevee, Assigned: Mardak)

References

Details

Attachments

(2 files, 4 obsolete files)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007081203 Minefield/3.0a8pre ID:2007081203

When hovering over any Download Manager UI elements, like the buttons "Open", "Retry", "Information" there is no feedback to indicate you are hovering over them. Same with the pane when you click on the Information button, it's not immediately obvious you can click the two menu items (they look like they're just for information purposes only).
Certainly a windows/linux only theme issue.  Mac buttons are not supposed to change when you hover over them.

Are you not getting a tooltip?
Oh sure, I get a tooltip, but I'm used to the button changing on hover too, like the rest of the ui (bevel effect and darkening of colours on firefox nav bar, just bevel on firefox bookmarks on bookmark toolbar, etc
we've been down the hover feedback path, we want it when we get real icons.
Pretty sure the icons we have are set now.. however one approach is to make the icons more transparent by default and fully opaque on hover. ?

The only icons we have are retry for finished downloads and pause/resume/cancel for active ones.
OS: Windows 2000 → All
Hardware: PC → All
Attached image screenshot of v1
opacity of .7 non-hover and 1 on hover.
Comment on attachment 301141 [details]
screenshot of v1

on all os? windows only? non-mac?

fyi, I'm hovering over the installer.exe button ;)
Attachment #301141 - Flags: ui-review?(madhava)
I don't think we should do this on OS X.
Attachment 301161 [details] has an example of what canceled looks like hovered vs paused not hovered (left picture)
Attached patch v1 (obsolete) — Splinter Review
Comment on attachment 301141 [details]
screenshot of v1

Hover states look different on different platforms.  The darkening works on mac (though the the 70% opacity makes them look a little disabled), but not on XP, Vista, or Linux.  I'll put in a request for hover-state versions of the icons.
Attachment #301141 - Flags: ui-review?(madhava) → ui-review-
Actually, we need depressed states too.  So, to be clear, that's

Pause:  Active, Hover, Depressed, Disabled
Resume: Active, Hover, Depressed
Cancel: Active, Hover, Depressed
Retry:  Active, Hover, Depressed
I'm not sure we can do depressed with CSS to be honest...
>I'm not sure we can do depressed with CSS

We will be doing all of the states with images
aye, but we can't select on "depressed" to change the image
Currently we have a lot of images like toolbar.png that contain 4 rows:

normal
hover
disabled
depressed

Can't we just a similar approach for the icons in the download manger?
I don't see why not.

.mini-button {}
.mini-button:hover {}
.mini-button[disabled="true"] {}
.mini-button:active {}
er, right...active.  Forgot about that one ;)
Attached patch v2 (obsolete) — Splinter Review
Assuming the icons go as they are now left/right for..
chrome://mozapps/skin/downloads/buttons.png
resume, cancel, pause, retry

and assuming they follow the order of..
chrome://browser/skin/Toolbar.png
normal, hover, disabled, depressed

seems like gnomestripe doesn't use hover/depressed states
Assignee: nobody → edilee
Attachment #301162 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #301444 - Flags: review?
UX team - any update on this?
>UX team - any update on this?

Get the code ready for normal, hovered, and hit states for all icons.
(In reply to comment #20)
> Get the code ready for normal, hovered, and hit states for all icons.
Edward's patch does that - we just need the images so he can get the right coordinates in the patch ;)
I'll let you know as soon as they are checked in, could be about a week.
Depends on: 430897
Attached patch v2.1 (obsolete) — Splinter Review
Based on the files for bug 430729.. assuming we change the packaging to downloadButtons.png instead of just having downloads.png <- downloadButtons.png

Slightly different from earlier.. the images in the drop are top->bottom normal, hover, active, disabled and as before.. left->right resume, cancel, pause, retry.
Attachment #301444 - Attachment is obsolete: true
Attachment #317830 - Flags: review?(sdwilsh)
Attachment #301444 - Flags: review?
Attached patch v2.2 (obsolete) — Splinter Review
Add in new icons and remove the old and update jar.mn
Attachment #317830 - Attachment is obsolete: true
Attachment #317896 - Flags: review?(sdwilsh)
Attachment #317830 - Flags: review?(sdwilsh)
Attached patch v3Splinter Review
The files are already added, so remove the unused ones.
Attachment #317896 - Attachment is obsolete: true
Attachment #318753 - Flags: review?(sdwilsh)
Attachment #317896 - Flags: review?(sdwilsh)
Comment on attachment 318753 [details] [diff] [review]
v3

r=sdwilsh

comment 3 indicates we want this for mac, and I thought we wanted it for Linux too.  What about those platforms?
Attachment #318753 - Flags: review?(sdwilsh) → review+
Mac already has the states from proto.

I didn't see any other linux using something like
moz-icon://stock/..&state=hover or &state=active

So I don't think there is? ?
Comment on attachment 318753 [details] [diff] [review]
v3

Theme update to use the icons landed from windows icon drops.
Attachment #318753 - Flags: approval1.9?
Comment on attachment 318753 [details] [diff] [review]
v3

a1.9=beltzner
Attachment #318753 - Flags: approval1.9? → approval1.9+
>I didn't see any other linux using something like
>moz-icon://stock/..&state=hover or &state=active

>So I don't think there is? ?

My impression is that we can't get alternate states of the gtk uplift icons, so we don't need to worry about it on linux.  cc'ing the linux themers in case I am wrong.
(In reply to comment #30)
> My impression is that we can't get alternate states of the gtk uplift icons, so
> we don't need to worry about it on linux.

Well, "can't" is relative: there's only one "state" for each GTK icon but engines can apply some transformations to them to make them look different. Mozilla currently does not allow the same. Note that most of the common GTK themes don't use hover or active states for icons, only buttons (which firefox supports just fine). The only exception is button icons without visible buttons, such as the search button (search bar). For this kind of icon, GTK apps don't have a common look btw... some apps lighten the icon up for hover, some do nothing. So in the end I don't think firefox is behaving notably odd in this case.
>So in the end I don't think firefox is behaving notably odd in
>this case.

Thanks for the clarification, not notably odd is of course what we are aiming to achieve :)
Proto already gave hover feedback, and this added for windows, and nothing for linux.

http://hg.mozilla.org/cvs-trunk-mirror/index.cgi/rev/698b73cbe37a
http://hg.mozilla.org/mozilla-central/index.cgi/rev/698b73cbe37a

Checking in toolkit/themes/winstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.36; previous revision: 1.35
done
Removing toolkit/themes/winstripe/mozapps/downloads/buttons.png;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/downloads/buttons.png,v  <--  buttons.png
new revision: delete; previous revision: 1.4
done
Removing toolkit/themes/winstripe/mozapps/downloads/buttons-aero.png;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/downloads/buttons-aero.png,v  <--  buttons-aero.png
new revision: delete; previous revision: 1.2
done
Checking in toolkit/themes/winstripe/mozapps/jar.mn;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/jar.mn,v  <--  jar.mn
new revision: 1.37; previous revision: 1.36
done
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3
Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050806 Minefield/3.0pre ID:2008050806
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.