426727 - Use consistent appearance for selected richlistitems

Status: NEW

(Toolkit :: Themes, enhancement)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

We need to decide what gradients to use on selected richlist view items:

-location bar autocomplete
-download manager
-addons manager

These interfaces should all reference the same file for consistency, we will likely want to do something with white and black with an alpha mixed with the highlight color to create a nice 3D feel.  I personally think the download manager gradient in Firefox 1 was one of the nicest visual aspects of the application.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

This CSS does wonders for the autocomplete richlist item, though I'm not sure we want to depend on a PNG that's located in /extensions (used for the download manager) for that.

.autocomplete-richlistitem[selected=true] {
 background-image: url(chrome://mozapps/skin/extensions/itemEnabledFader.png) ! important;
 background-color: highlight ! important; 
}

On Vista, I'd still rather we use the -moz-appearance: menuItem.

Doesn't block, but I might try to do this myself tonight.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

>This CSS does wonders for the autocomplete richlist item

I find it impossible to see with two line items, and pretty difficult to see with larger items in the download manager.  Also we are kind of inverting our light source compared to every other texture and icon in the app.

>On Vista, I'd still rather we use the -moz-appearance: menuItem.

Totally agree, or just use a png that matches -moz-appearance: menuItem

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

>and pretty difficult to see with larger items in the download manager.

sorry, meant addons manager.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

this bug is eligible for bug 462081

Comment 5

[ronin.achilles]

Attachment: Autocomplete Vista style Gradient Highlight

Following userchrome.css hack does the trick pretty well (See attachment). Maybe we could use something similar.

/*:::::::::::::::::::::::: Autocomplete ::::::::::::::::::::::::::*/

.autocomplete-richlistbox > richlistitem
{
border: none !important;
}

.ac-comment 
{
font-size: 125% !important;
}

.autocomplete-richlistitem:not([selected="true"])
{
margin: 0px 3px 0px 3px !important;
}

.autocomplete-richlistitem[selected=true] {
background: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAyCAIAAAASmSbdAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAB3RJTUUH2AofCxIS92uF8AAAAAd0RVh0QXV0aG9yAKmuzEgAAAAMdEVYdERlc2NyaXB0aW9uABMJISMAAAAKdEVYdENvcHlyaWdodACsD8w6AAAADnRFWHRDcmVhdGlvbiB0aW1lADX3DwkAAAAJdEVYdFNvZnR3YXJlAF1w%2FzoAAAALdEVYdERpc2NsYWltZXIAt8C0jwAAAAh0RVh0V2FybmluZwDAG%2BaHAAAAB3RFWHRTb3VyY2UA9f%2BD6wAAAAh0RVh0Q29tbWVudAD2zJa%2FAAAABnRFWHRUaXRsZQCo7tInAAAAL0lEQVQImWN49e0v038GBiYGJIzOZ%2FiPKf4fjxyKWXjk%2FzP8x2svTC%2ByHLq9UAwAMpcVLv4KFmYAAAAASUVORK5CYII%3D") repeat-x center !important;
background-color: highlight ! important; 
border: 1px solid  #99DEFD !important;
margin: -1px 2px -1px 2px !important;
color: black !important;
-moz-border-radius: 4px !important;
}

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

Expanding bug to all platforms.

Comment 8

[Nochum Sossonko [:Natch]]

This should be doable with css when bug 479220 is fixed. Maybe there should be a new -moz-appearance type (i.e. -moz-richlistbox)?

Comment 9

[Dão Gottwald [:dao]]

Attachment: WIP

Comment 10

[Dão Gottwald [:dao]]

Attachment: patch

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug's priority relative to the set of other polish bugs is:
P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.

Impacts the primary UI in terms of the awesome bar (which the user encounters several times a day), and a number of secondary interfaces as well.

Comment 12

[Dão Gottwald [:dao]]

Attachment: patch

updated to trunk

Comment 13

[Dão Gottwald [:dao]]

Comment on attachment 389090 [details] [diff] [review]
patch

tryserver builds:

https://build.mozilla.org/tryserver-builds/[e-mail]-try-cb0054ae5b61/

Comment 14

[Dão Gottwald [:dao]]

Attachment: patch

updated to trunk

https://build.mozilla.org/tryserver-builds/[e-mail]-try-4f10134e1d9a/

Comment 15

[Ryan Flint [:rflint] (ping via IRC for reviews)]

Comment on attachment 390713 [details] [diff] [review]
patch

>diff --git a/toolkit/themes/winstripe/mozapps/extensions/extensions-aero.css
>+richlistitem[isDisabled="true"][selected="true"]:-moz-system-metric(windows-default-theme) {
Should probably get a follow up on file for making the EM set @disabled in addition to/in lieu of @isDisabled so we can pick up aero's disabled item styling (or expose the disabled style to CSS).

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

Still in the process of trying this out on all the platforms, but so far the one thing I've noticed is the error console potentially hard coding a color that didn't get updated along with the rest of the richlist views.

Comment 17

[Nochum Sossonko [:Natch]]

(In reply to comment #16)
The error console doesn't use richlistbox or richlistitems, and fixing that would automatically include this fix.

Comment 18

[Andrés Delfino]

Reopened bug 418598 to fix Error console.

Comment 19

[Nochum Sossonko [:Natch]]

Does this remove the border from unselected richlistitems? I suspect that would be an unwanted change, I'll attach a screenshot of what I saw with this patch applied.

Comment 20

[Nochum Sossonko [:Natch]]

Attachment: screenshot of applied patch

Here's the screenshot, notice that there's no bottom border for the unselected richlistitems. This is on trunk/Vista.

Comment 21

[Dão Gottwald [:dao]]

(In reply to comment #20)
> notice that there's no bottom border for the unselected richlistitems.

That's expected. See for instance your own work in bug 445639 :)

Comment 22

[Nochum Sossonko [:Natch]]

That patch had a hover effect in it that visually distinguished the various richlistitems, IMHO that should be the desired effect, at least on Windows. Windows Explorer uses a similar technique...

Comment 23

[Dão Gottwald [:dao]]

The menuitem appearance is the closest thing we have, but it lacks a distinct hover state. I'm all for implementing what Explorer does in widget:windows. Any volunteers?

Comment 24

[Alex Faaborg [:faaborg] (Firefox UX)]

Really sorry about the lag on the ui-review.  I'm not finally back in the office and I can get you a review if post some tryserver builds, since I want to check this out on all platforms.

Comment 25

[Alex Faaborg [:faaborg] (Firefox UX)]

sorry, mean "now finally back", !"not finally back"

Comment 26

[Alex Faaborg [:faaborg] (Firefox UX)]

We need to test this out on windows 7 since I think the original patch was meant to match Vista.

Comment 27

[ronin.achilles]

Requesting to Block Bug 544820. This is an easy patch. Can we land this along with all the theme changes taking place on trunk right now?

Comment 28

[Nochum Sossonko [:Natch]]

Would be nice to see this last-of-the-mohicans (yes, I know there are more, but this one is from the first few) polish-p1 patch go in... :)

Comment 29

[Alex Faaborg [:faaborg] (Firefox UX)]

Some new color values for windows 7 (in case we can't extract them):

outline color="#aeccf1"
gradient top color="#fafbfd"
gradient bottom color="#ebf3fd"

Comment 30

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 390713 [details] [diff] [review]
patch

it would be great if we could get this landed at some point.  sorry for the long delay in ui-review (updated my searches to include all products).  Can you attach a screen shot at some point for a quick ui-review?

Overall goal is to match the Windows highlight (not the classic theme highlight color, but the gradient they use in explorer, traditional menus, and the start menu).

The colors I sampled came to:

outline: color="#7a9fcb"
gradient top color="#dceafc" (100%)
gradient bottom color="#c1dbfc" (100%)

Comment 31

[Alex Faaborg [:faaborg] (Firefox UX)]

sorry, those values were for downclick selected, here is the more common hover state:

selected hover
outline color="#b8d6fb"
gradient top color="#fafbfd" (100%)
gradient bottom color="#ebf3fd" (100%)

Comment 32

[u310142]

This currently does not look great on win8+. This would fix that:

.autocomplete-richlistitem[selected="true"] {
    background: #D1E8FF !important;
    outline: 1px solid #66A7E8 !important;
    -moz-outline-radius: 0px !important;
    background-clip: content-box !important;
}

Comment 33

[u310142]

I just realized I made the same mistake as Faaborg, and used the colors of the selected state. :P
Here it is again, but this time with the colors of the hover state:

.autocomplete-richlistitem[selected="true"] {
    background: #E5F3FB !important;
    outline: 1px solid #70C0E7 !important;
    -moz-outline-radius: 0px !important;
    background-clip: content-box !important;
}