Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre The Firefox Button is reusing menu labels from the standard menus, like "Clear recent history..." from the Tools menu in Firefox Button->History, but it doesn't seem to use the same widths. See for example "Cancella cronologia recente..." in the Italian version.

Any news on this? I tried also shortening the translation (from "Cancella la cronologia recente" to "Cancella cronologia recente", removing 3 characters) but the label is not fully displayed, so I'm a bit stuck with this.

Is this still a problem with the current version of the firefox button menu? If so, I can own it and fix it.

(In reply to comment #3) > Is this still a problem with the current version of the firefox button menu? If > so, I can own it and fix it. Hi Margaret, this problem it's still present (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20101005 Firefox/4.0b7pre).

I'm having trouble reproducing this problem. None of the en-US strings overflow the menuitem width, but my history entries are getting cut off at the same point. As far as I can tell, the same css rules are applying to both menuitems. A max-width of 42em is set for both of them here: http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/winstripe/global/menu.css#192. I can't find any menuitem styles specific to the firefox button menu, so I'm not really sure what's going on for you. Have you ever experienced issues like this before?

(In reply to comment #5) > I'm having trouble reproducing this problem. Also with an Italian build? > Have you ever experienced issues like this before? Do you mean with the Italian localization? We never had problems like this on Windows. We had some problems in the past on Mac and we shortened the strings when necessary, what I don't understand is the different behavior between the standard menu and the app button.

Bookmarks items have a 26em max-width: http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#448

Hmm, I was confused. This isn't bookmarks related. Sorry. But menus want to have a maxwidth, for example, because bookmarks could have long urls. I wonder if using a larger max-width would fix the issue? Not really the right fix though, since another menuitem might need a few more pixels more than that.

Any chance to see this fixed? I'm asking because the only solution on my side is to change the localization, and I don't really like to do that unless there's no other available option.

Hi, Margaret and Francesco. Using an italian build I have the same problem and I resolved it changing this: menupopup > menu, menupopup > menuitem { max-width: 42em; } to this: menupopup > menu, menupopup > menuitem { max-width: 42em !important; }

The problem is that a different max-width (26em) is being set on the .bookmark-item menutiems: http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#448. The reason these menupopups have different widths then is because the Tools menu doesn't have any bookmark-item menuitems in it. It seems like the proper solution would be to get rid of that max-width set on menuitem.bookmark-item, although I don't know the reason behind that style rule.

I think we should get rid of the max-width on menu.bookmark-item and menuitem.bookmark-item. However, this will potentially make the menus much wider if there is a long bookmark title. Alex, is that acceptable? Or should there be a different max-width for all menus?

>Alex, is that acceptable? Or should there be a different max-width for all >menus? Let's set a new max-width just for the menus that have longer strings. Right now the history menu is considerably wider than the bookmarks menu (shown here). We should make those two sub menus the same, and wide enough that locales don't crop. Side question: can locales change these values themselves? I was under the impression that they could.

(In reply to comment #13) > Side question: can locales change these values themselves? I was under the > impression that they could. Not that I know of. We can change some widths, but that value must be available as an entity (e.g. http://mxr.mozilla.org/l10n-central/source/it/browser/chrome/browser/preferences/preferences.dtd). Axel can correct me if I'm wrong ;-)

What flod said, if we expect localizers to adjust that width, it should be in an entity. There's also intl.css, where localizers can overwrite rules, but that's hacky and hard to get right. Perhaps the more challenging part is that this implies moving the rule from theme to l10n, which probably calls out an add-on compat issue for themes. Also, I don't have context why it's in theme in the first place.

We can file a followup for full-l10n control of the width, I don't think that's necessary to do here. Let's just go with Alex's suggestion for now: "make those two sub menus the same, and wide enough that locales don't crop".

>uiwanted these should be wide enough for localized strings, but I think the toolkit setting of 42 is likely going to appear way too wide.

I increased the max-width for the .bookmark-item menuitems to 32em. This increase prevents the Italian string from being cut off, and leaves some wiggle room in case there are other locales with slightly longer strings. Although there may be some locales with strings that still get cut off, that risk has to be weighed against the fact that increasing this max-width value more increases the width of the history/bookmarks menus for all locales, and as Alex said, the default 42em is likely to appear way too wide. Like Gavin said, we can file a follow-up for a more perfect solution, but I think this is good for addressing the blocking issue.