531140 - styling in message view select widget and folder location select widget a mess

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Asa Dotzler [:asa]]

Attachment: image showing incorrect styles and correct styles

The style for text and selection in the message view widget and the folder location select widget is a mess. It shows three wrong styles. First, it's white on white in some cases. Second it's black on blue in some cases. Third it's white on blue in some cases. Fourth, the background and border is not the correct style either and there's no space for icons.

The correct selection color is a blue outline on the selected item with black text.

Comment 1

[Mark Banner (:standard8)]

Not going to block 3.0 for this, but we want a patch for an expected quick turn around 3.0.1 release.

Comment 2

[Andreas Nilsson (:andreasn)]

Attachment: native windows dropdown

I wonder if all the wrongs in the example are really wrongs. Looking around in other Vista apps it seems like dropdowns tend to look this way across the system.
The one that changes color is indeed a issue though.

Comment 3

[Andreas Nilsson (:andreasn)]

To follow up, as these are  menulists rather than a menus, it should probably be solid blue hover on white background as seen in the current folder location dropdown.

The odd blue rounded hovers with white text seems to be because the controls are using type="radio" in extraCustomizeItems.xul (and sometimes checkboxes?). Still investigating on how to fix that.
Not sure what to do with the submenus, as I can't find any other examples on a situation where these are used in menuitems, but it would probably make sense to make these use solid blue on white instead of mimicking regular menus.

Comment 4

[Andreas Nilsson (:andreasn)]

Attachment: possible fix

I'm not quite certain about this approach, as it might be better handled in the global toolkit bits (?), but it takes care of the color issue at least.

Comment 6

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 417702 [details] [diff] [review]
possible fix

I would love a screenshot of this as I don't have windows 7 to test with

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> (From update of attachment 417702 [details] [diff] [review])
> I would love a screenshot of this as I don't have windows 7 to test with

Andreas: ping for the above.

Comment 8

[Andreas Nilsson (:andreasn)]

Attachment: screenshot of patch in Win7

Comment 9

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 417702 [details] [diff] [review]
possible fix

Ok, that looks better to me.  Perhaps we keep this bug open for further issues we find.

Comment 10

[Phil Ringnalda (:philor)]

Comment on attachment 417702 [details] [diff] [review]
possible fix

Sorry, I kept hoping I'd manage to tell you what to do, not just what not to do, but

>+#folderLocationPopup > *:hover {

The English translation of that selector is "every single time that any element anywhere that mailWindow1.css is applied goes into the :hover state, stop, walk up the DOM to its parent element, and look up the id of its parent element to see if it's folderLocationPopup, whether or not (and since it requires customization, and is only really useful if you want to hide the folderpane because you loved that in NS4.x, in 99.9% of the cases that's going to be not) there is any element anywhere in the entire DOM with that id.

Too expensive, we need something that is at least only as horribly, grotesquely expensive as http://mxr.mozilla.org/comm-central/source/mail/themes/qute/mail/folderMenus.css#138 (or, for major massive bonus points, fix this and that both at once, so we don't have either one doing things that https://developer.mozilla.org/en/CSS/Writing_Efficient_CSS says multiple times are absolutely prohibited).

Comment 11

[Andreas Nilsson (:andreasn)]

Attachment: updated patch that is less evil

This also make the folder selector widget look consistent with itself.

Comment 12

[Andreas Nilsson (:andreasn)]

Comment on attachment 437313 [details] [diff] [review]
updated patch that is less evil

Lets see if this works better.

Comment 13

[Mark Banner (:standard8)]

I think given where we are, this is a wanted improvement for Thunderbird.

Comment 14

[David Ascher (:davida)]

i'm pretty sure mark didn't intend to mark it confidential

Comment 15

[Phil Ringnalda (:philor)]

Comment on attachment 437313 [details] [diff] [review]
updated patch that is less evil

Apparently I'm never going to get around to rooting out all evil, so lesser evil is probably a good idea.

Comment 16

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/6e93b14fc929