The background color of the bookmarks and history side bars on Vista should be set to (238,243,250). This bug depends on bug 425598.

The CSS fix should be this, tried using Stylish on Firefox3b4: #sidebar-splitter{ border: 0 !important; -moz-border-right-colors: none !important; border-right: 1px solid #a9b7c9 !important; background-color: transparent !important; min-width: 0 !important; } This applies to *any* sidebar of the browser content area. Might affect sidebar-related extensions as well.

From an email conversation with beltzner: >-style vista sidebars blocking: this is just the CSS fixes? Yes, and one image change (bug 425998)

Oops, submitted this on the wrong bug. Sorry. :(

(In reply to comment #0) > The background color of the bookmarks and history side bars on Vista should be > set to (238,243,250). This bug depends on bug 425598. I don't think it depends on that at all; high-contrast text on that background should look fine, shouldn't it? I also don't think it depends on bug 425998, but maybe the colours don't match nicely there?

Alex, what's the system native fallback we'd use in the accessibilty/no-bug-425998 case?

What it should currently be: Window. >high-contrast text on that background >should look fine, shouldn't it? The reason I set this to depend on bug 425998 is because it uses a hard coded color. The distinction isn't "do we think we have enough contrast" but do we use system colors. For instance, some people use high contrast mode because the are very light sensitive and get migraine headaches when exposed to too much light. So black on white (or in this case black on grey) is probably enough contrast, but still doesn't support high contrast mode.

Yup, and that's now more solved by bug 426660. I'm not sure that this blocks in the way that I feel the different splitter styling blocks, but we should be able to do both at the same time.

I'm removing blocking on this. The meat of the patch (from attachment 317023 [details] [diff] [review]) is: +#placesView:-moz-system-metric(windows-default-theme), +#searchModifiers:-moz-system-metric(windows-default-theme), +#infoPane:-moz-system-metric(windows-default-theme), +#placesList:-moz-system-metric(windows-default-theme), +#placeContent:-moz-system-metric(windows-default-theme) { + background-color: #EEF3FA; +} but I'm having trouble making it work in all sidebars. I also think that while it's a wanted change, it's less visible than others like getting -moz-appearance: menuItem working properly on selection. I'll keep poking at it, but let's not hold ship for it.

this bug is eligible for bug 462081

Not sure what the right way to fix this is -- I see various "we need bug xxxxx" comments above, but it's not clear which of them are really needed or the expected way to fix this.

>but it's not clear which of them are really needed or the >expected way to fix this. The change needs to be for just the Vista Aero theme. As far as I understand, we achieve the just Vista part with separate css files, so the change needs to be in the file browser-aero.css (I think). To make sure the user is using the Aero theme (as opposed to classic, or a high contrast theme accessibility theme) we use -moz-system-metric(windows-default-theme) So for example, we can see a very similar change to set the background color in the places organizer: http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/places/organizer-aero.css#55 I'm not sure exactly where the css for the sidebars lives however.

the problem is that the sidebar loads a sub page, and so the background is not easily settable for all contents that could be shown into it. Hwv we can set it for history/bookmarks sidebars. For the same reason, even if it would be much cleaner having the header with same color like in many Vista dialogs, it would appear badly with external contents, so it should stay with a toolbox style. Taking for now, i'll ask ui-review on that.

this should do the trick

Comment on attachment 355769 [details] [diff] [review] patch This doesn't really work -- missing preprocessing hint in jar.mn.

uh, oops

Comment on attachment 355968 [details] [diff] [review] patch >+#bookmarksPanel:-moz-system-metric(windows-default-theme) > tree, >+#history-panel:-moz-system-metric(windows-default-theme) > tree { >+ background-color: #EEF3FA; >+ border: none; >+} make this: .sidebar-placesTree:-moz-system-metric(windows-default-theme) { background-color: transparent; border-top: none; }

why only border-top?

places.css specifies only a top border, which is what we want to override.

addressed Dao's comments

Comment on attachment 356169 [details] [diff] [review] patch I thought this was a places bug, but is in Themes, so Dao's review should be enough.

Comment on attachment 356172 [details] [diff] [review] for checkin This doesn't use .sidebar-placesTree per comment 16.

(In reply to comment #22) > (From update of attachment 356172 [details] [diff] [review]) > This doesn't use .sidebar-placesTree per comment 16. what?

Er, sorry, I misread the patch. Nevermind!

attachment 356169 [details] [diff] [review] didn't use .sidebar-placesTree as it should have, Marco fixed that in attachment 356172 [details] [diff] [review].

Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090131 Minefield/3.2a1pre ID:20090131034630

Comment on attachment 356172 [details] [diff] [review] for checkin a191=beltzner

Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090312 Shiretoko/3.1b4pre ID:20090312054420

This bug's priority relative to the set of other polish bugs is: P3 - Polish issue that is in a secondary interface, occasionally encountered, or is not easily identifiable. sidebars are secondary UI, and the difference isn't all that obvious