Menupopup of "Default font" isn't using the full width, cuts of font-names

RESOLVED FIXED in Thunderbird 36.0

Status

defect
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: elbart, Assigned: foss)

Tracking

Trunk
Thunderbird 36.0

Thunderbird Tracking Flags

(thunderbird36 fixed)

Details

Attachments

(5 attachments)

Posted image tb_font_picker.jpg
The menupopup for choosing "Default font" is not using the full width of the menulist-button, and because of that it's cutting off font-names.
And it doesn't look very good, too.
Also on Mac for latest trunk build
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 7 → All
Assignee: nobody → leofigueres
Posted patch 986078.patchSplinter Review
Changing sizetopopup on the menulist fixes the problem on Linux.

On OS X it was needed to make the width greater, also.

I have been unable to test it on a Windows machine. However, comparing attachment 8394316 [details] with the result on my Linux box, I think it will also work. On both of them, popup is smaller than the menulist.

On Mac it was reversed: menu popup was bigger than menulist.

Mark, could you take a look into this patch, please? Thank you.
Attachment #8449795 - Flags: review?(standard8)
Here it is shown the popup with fixed width size on both OS X and Linux. No ellipses have been found on any item when menu is unfolded.
Attachment #8449807 - Flags: ui-review?(bwinton)
Comment on attachment 8449795 [details] [diff] [review]
986078.patch

Someone like Mike is probably better to review this than me.
Attachment #8449795 - Flags: review?(standard8) → review?(mconley)
Comment on attachment 8449807 [details]
screenshot with fixed popup width

Yep, fairly obviously better.  Thanks for the patch!
Attachment #8449807 - Flags: ui-review?(bwinton) → ui-review+
The bug was about Windows. Althought patch fixed the problem also on OS X and Linux, I didn't provide a screenshot for Windows. Here it is.
Attachment #8449795 - Flags: review?(mkmelin+mozilla)
For me the font picker seems to be broken in current trunk (is empty and I get errors in console). Is that a known bug or should I file it?
Hardware: x86_64 → All
Version: unspecified → Trunk
(In reply to :aceman from comment #7)
> For me the font picker seems to be broken in current trunk (is empty and I
> get errors in console). Is that a known bug or should I file it?

I have been unable to build Thunderbird from some days ago. I will wait until those build-config changes finally stabilize. So I have downloaded latest trunk build from ftp.mozilla.org. On my OS X 10.9 system, pop-up is correctly showing fonts and no error appears in my Error Console.

There are, however, some error appearing on the console when opening the Advanced sub-dialog. I have not gone too deeply into this, but one possible explanation is:

* Menu pop-ups on Advanced sub-dialog are depending on the charset selected on the upper-most part of the window (Unicode, Western, Japanese...)

* Font selections pop-up are then updated to show which possible values can be selected depending on that upper selection.

* Preferences name which are linked with those menu pop-ups are dynamically changed. Those changes, however, take some time to process.

* When we try to access "preference.value" on the related JS code, that preference name (each charset has its own Monospace font preference, for example) maybe has not been updated still, Then the error is shown in the Error Console.

No bug has been opened about this, as far as I know.
Comment on attachment 8449795 [details] [diff] [review]
986078.patch

Review of attachment 8449795 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch!  
I have to say I'm not sure if prefWindow.styleMac should be bumped in this case, or if this can be seen as a thing localizers should adjust.
Attachment #8449795 - Flags: review?(mkmelin+mozilla)
Attachment #8449795 - Flags: review?(mconley)
Attachment #8449795 - Flags: review+
This screenshot shows that Catalan release for Thunderbird also is showing the problem. It is showing 52em for prefWindow.styleMac. Spanish one showed the same problem.

http://mxr.mozilla.org/l10n-central/source/ca/mail/chrome/messenger/preferences/preferences.dtd

As far as I know, US release is using files modified by this patch, not a particular locale. Other English locale version of the file is the British one, which shows 47 em.

Should we add a notice on this bug report so that localizers take it into account?
Yes, the "default" releases use files modified by this patch. What I meant was that usually when we change a localized value we have to change the localization key (e.g. to prefWindow.styleMac2 in this case) so that we can be sure localizers notice. 

Having thought about it some more - this value is one that localizers should adjust (and may well have adjusted), I think we can just leave the patch as it is.

Notices can be sent to the mozilla localizations newsgroup.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 36.0
You need to log in before you can comment on or make changes to this bug.