The default bug view has changed. See this FAQ.

Submenus in Firefox Button should be larger (localized strings are not fully displayed)

RESOLVED FIXED

Status

()

Firefox
Menus
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: flod, Assigned: Margaret)

Tracking

({regression})

Trunk
x86
Windows 7
regression
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [hardblocker])

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
Created attachment 463763 [details]
Screenshot of the menu in the Firefox button

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.
(Reporter)

Comment 1

7 years ago
Created attachment 463764 [details]
Same menu item correctly displayed in the standard menu Tools
(Reporter)

Updated

7 years ago
Component: General → Menus
QA Contact: general → menus
blocking2.0: --- → ?
blocking2.0: ? → betaN+
(Reporter)

Comment 2

7 years ago
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.
(Assignee)

Comment 3

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

Comment 4

7 years ago
(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).
(Assignee)

Comment 5

7 years ago
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?
(Reporter)

Comment 6

7 years ago
(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.
Keywords: regression

Comment 7

6 years ago
Bookmarks items have a 26em max-width:

http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#448

Comment 8

6 years ago
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.
(Reporter)

Comment 9

6 years ago
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.

Comment 10

6 years ago
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;
}
(Assignee)

Comment 11

6 years ago
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.
Assignee: nobody → margaret.leibovic
(Assignee)

Comment 12

6 years ago
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?
Keywords: uiwanted
>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.
Whiteboard: [hardblocker]
(Reporter)

Comment 14

6 years ago
(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 ;-)

Comment 15

6 years ago
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.
Whiteboard: [hardblocker] → [hardblocker][strings]
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.
Keywords: uiwanted
(Assignee)

Comment 18

6 years ago
Created attachment 503312 [details] [diff] [review]
patch

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.
Attachment #503312 - Flags: review?(gavin.sharp)
Attachment #503312 - Flags: review?(gavin.sharp) → review+
Whiteboard: [hardblocker][strings] → [hardblocker]
(Assignee)

Comment 19

6 years ago
http://hg.mozilla.org/mozilla-central/rev/a4cbf4b8928b
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Depends on: 625369
You need to log in before you can comment on or make changes to this bug.