Reproducible on the latest Nightly (BuildID: 20140407030203) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 Not reproducible on: the latest Aurora (BuildID:20140407004002): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20130205 Firefox/30.0 the latest Beta (BuildID:20140407135746) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20130205 Firefox/29.0 On the Aurora and Beta versions, the issue doesn’t appear because the UI for in-content preferences is different here. Steps to reproduce: 1. Open about:preferences. 2. Go to Privacy tab, on History and select "Nightly will Use custom settings for history" 3. Observe the button labels. Actual results: The button labels aren't entirely visible (See screenshot "3.PNG") Expected results: The button labels are correctly displayed. Notes: This issue is not a regression.

In fact, this issue happens for all drop-down lists when you select the longest item : * General > When Nightly starts > "Show my windows and tabs from last time" * Privacy > Keep until > "ask me every time" * etc. Note: font size selection seem to be the only exception.

The in-content menulists have more spacing than the standard menulists. I've added more padding to the menu/menuitems to let calculate the correct menulist width. The 10px on theft are to align the text in popup with the menulist's text. I also removed the no more needed min-width for #defaultFontSize. I had also to add the font-family to menu/menuitem to override the font-family in default rule.

Comment on attachment 8409316 [details] [diff] [review] inContentMenulistLabel.patch Review of attachment 8409316 [details] [diff] [review]: ----------------------------------------------------------------- so, 30px is basically 10px spacing, 10px dropdown, 10px spacing, right? what are the osx changes for? Looks like it's hiding the checkmark, but I don't see a rationale for that in this bug. That said, I don't think I'm the most suitable person to mark this, since I'm not sure which direction we want to take for this theme part, so I think I'm going to forward the request to Dao.

The rationale is bug 993373, where the selected items have a darker blue and the hovered a lighter one.

(I'll review this next week if Dao doesn't get to it before then)

Comment on attachment 8409316 [details] [diff] [review] inContentMenulistLabel.patch Review of attachment 8409316 [details] [diff] [review]: ----------------------------------------------------------------- r=me with the following change: ::: browser/themes/osx/preferences/in-content/preferences.css @@ +5,5 @@ > %include ../../../shared/incontentprefs/preferences.css > > +menulist:not([editable="true"]) > menupopup > menuitem[checked="true"]::before, > +menulist:not([editable="true"]) > menupopup > menuitem[selected="true"]::before { > + display: none; Let's revert this change. While we now have better styling to show what is selected and what is hovered, it is platform convention on Mac to put a checkmark next to selected items.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6) > Comment on attachment 8409316 [details] [diff] [review] > inContentMenulistLabel.patch > > Review of attachment 8409316 [details] [diff] [review]: > ----------------------------------------------------------------- > > r=me with the following change: > > ::: browser/themes/osx/preferences/in-content/preferences.css > @@ +5,5 @@ > > %include ../../../shared/incontentprefs/preferences.css > > > > +menulist:not([editable="true"]) > menupopup > menuitem[checked="true"]::before, > > +menulist:not([editable="true"]) > menupopup > menuitem[selected="true"]::before { > > + display: none; > > Let's revert this change. While we now have better styling to show what is > selected and what is hovered, it is platform convention on Mac to put a > checkmark next to selected items. When I revert this, I need to leave the left-/right-padding of 21px defined in toolkit to show the checkmark entirely. Now my question: should I set the padding on Linux/Windows files or leave it in shared and revert the padding in OS X file?

I choosed adding the padding on Linux and Windows only.

I'm not really happy with the decision to leave the checkmarks on OS X. The in-content design was made to look similar on all platforms, which means it hasn't the need to look native. Now we are special casing OS X with this checkmarks where the menuitem coloring should be the indicator. With this checkmarks also the aligning between the text in menubutton and popup text is totally off. So please let's use the direction of attachment 8409316 [details] [diff] [review].

Michael, can you please clear up what we should do in regards to comment #6 and comment #12?

John Gruen and I have been making progress on Project Chameleon, specifically nailing down our inContent style. You can find the working documentation here: http://people.mozilla.org/~jgruen/chameleon/#nav0 I would recommend changing the labels to hex value #333333, as you can see in the documentation and attached example. Also, we should not be making special cases for each platform in terms of style. That was the whole idea around the inContent UI being platform neutral. It can work anywhere. We're still fine-tuning the details, but I believe we are getting there.

Comment on attachment 8409316 [details] [diff] [review] inContentMenulistLabel.patch Thanks for the response Mike. Let's go with the original patch :)

I changed all color: #737980; to color: #333333; for using only one color on all buttons, textareas etc.

Comment on attachment 8425567 [details] [diff] [review] inContentMenulistLabel.patch Review of attachment 8425567 [details] [diff] [review]: ----------------------------------------------------------------- LGTM

Try: https://tbpl.mozilla.org/?tree=Try&rev=30148171c465

Verified fixed on Windows 7 64bit and 32bit using latest Nightly 32.0a1 (buildID: 20140522030204).