In gnomestripe, winstripe and pmstripe themes icons do not show up for menuitems in a menupopup even if they have one due to certain css. http://lxr.mozilla.org/seamonkey/source/toolkit/themes/gnomestripe/global/menu.css#179 http://lxr.mozilla.org/seamonkey/source/toolkit/themes/winstripe/global/menu.css#196 http://lxr.mozilla.org/seamonkey/source/toolkit/themes/pmstripe/global/menu.css#189 Looking at pinstripe that does not have "display: none" One option is to remove the display: none rule or another is to do the same as pinstripe (sets a margin).

The rules being removed only applies to drop-down menu lists (combo boxes) and not to regular menus. Removing these rules mean that existing drop-downs will now have extra space on the left that need to be dealt with (since menu-iconic-left is given a min-width, and menu items in drop-down boxes are treated as an iconic menu item instead of a regular non-iconic menu items, regardless of whether they are iconic or not). Personally, I think the binding should be changed so that menu items in menu lists are not bound as iconic menu items all the time, and then removing these rules will make more sense.

(In reply to comment #1) > The rules being removed only applies to drop-down menu lists (combo boxes) and > not to regular menus. Removing these rules mean that existing drop-downs will > now have extra space on the left that need to be dealt with (since > menu-iconic-left is given a min-width, and menu items in drop-down boxes are > treated as an iconic menu item instead of a regular non-iconic menu items, > regardless of whether they are iconic or not). > > Personally, I think the binding should be changed so that menu items in menu > lists are not bound as iconic menu items all the time, and then removing these > rules will make more sense. > Trouble is, as someone pointed out to me earlier, if you have some menu items being iconic and others not then they will look messy. Maybe you would have to set the iconic status at the menulist level rather the menuitem level but without digging more into it I do not know if that is possible solution or not. I would say the current patch is a bandaid rather than a full solution.

(In reply to comment #2) > Trouble is, as someone pointed out to me earlier, if you have some menu items > being iconic and others not then they will look messy. > Well, they already look messy. If you look at the menulists that do contain icons (e.g., RSS feed dropdown or MIME handler dropdowns), there are alignment issues with iconic and non-iconic items, and these need to be resolved. > Maybe you would have to set the iconic status at the menulist level rather the > menuitem level but without digging more into it I do not know if that is > possible solution or not. > Yes, that is definitely possible, and I think that's probably the best thing to do for menulists because, unlike regular menus, we do not want the margin on the left if all the items are non-iconic. > I would say the current patch is a bandaid rather than a full solution. > Having the patch address the left margin that will appear when these rules are removed isn't just a matter of finding a "full solution"--it is necessary to prevent regressing the appearance of most uses of menulists. The patch as posted will mess up the appearance of text-only menulists.

Items in menulists do not (and in my opinion, should not) support images. The image area to the left is reserved for the checkmark that appears on Mac, or anyother platform/theme for the selected item.

Comment on attachment 328065 [details] [diff] [review] menulist icon patch v0.1 r- per comments from Kai/Neil. Neil's a better reviewer for something like this anyways.

In Thunderbird on linux running GNOME (Ubuntu 9.04), the display: none stuff actually breaks checkmark/radio button display in our mailviews toolbar item. Also, it is inconsistent because the sub-menus in the menulist's menupopup do have the whitespace for the checkmark/radio button. I am just going to clobber the display: none directive with something in messenger.css in gnome-stripe because we will ship with 1.9.1 which is, for all intents and purposes, frozen. But it would be nice to fix/understand this (in the case what I'm seeing is a regression).