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

Status: RESOLVED FIXED

(Thunderbird :: Preferences, defect)

Description

[Elbart]

Attachment: 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.

Comment 1

[Javi Rueda :javirid]

Also on Mac for latest trunk build

Comment 2

[Javi Rueda :javirid]

Attachment: 986078.patch

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.

Comment 3

[Javi Rueda :javirid]

Attachment: screenshot with fixed popup width

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.

Comment 4

[Mark Banner (:standard8)]

Comment on attachment 8449795 [details] [diff] [review]
986078.patch

Someone like Mike is probably better to review this than me.

Comment 5

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8449807 [details]
screenshot with fixed popup width

Yep, fairly obviously better.  Thanks for the patch!

Comment 6

[Javi Rueda :javirid]

Attachment: Screenshot on Windows 8

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.

Comment 7

[:aceman]

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?

Comment 8

[Javi Rueda :javirid]

(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 9

[Magnus Melin [:mkmelin]]

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.

Comment 10

[Javi Rueda :javirid]

Attachment: Screenshot from Spanish Release Thunderbird

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?

Comment 11

[Magnus Melin [:mkmelin]]

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.

Comment 12

[aleth [:aleth]]

https://hg.mozilla.org/comm-central/rev/d2a7f4929f63