Closed Bug 1268520 Opened 4 years ago Closed 4 years ago

Composition / general pref panel cut off if the font dropdown box is very wide (due to an unusually long font name in the list)

Categories

(Thunderbird :: Preferences, defect)

45 Branch
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 50.0

People

(Reporter: jeff, Assigned: aceman)

References

Details

Attachments

(5 files, 5 obsolete files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160421124000

Steps to reproduce:

Updated to version 45 of Thunderbird


Actual results:

When you go to PREFERENCES > COMPOSITION > GENERAL half the screen is cut off and you can not change/see those settings. See attached pic.


Expected results:

Should be able to see all the options on the screen.
OS: Unspecified → Mac OS X
Do you have a dual monitor setup, one retina and one not?
Flags: needinfo?(jeff)
The issue also happens on the PREFERENCES > COMPOSITION > ADDRESSING screen as well.
@Wayne - I am using a 2011 MacBook Pro which I beleive does not have a retina display at all. I do use an external monitor on it sometimes, but even when I have no external monitor hooked up and am just using the laptop all by itself, the issue still occurs on the laptop screen.
Flags: needinfo?(jeff)
Does problem go away in safe mode?
 https://support.mozilla.org/en-US/kb/safe-mode
Flags: needinfo?(jeff)
See Also: → 1268516
No, the problem does not go away in safe-mode and is still there.
Flags: needinfo?(jeff)
Can the preferences window be set so that it is resizeable? If I could resize it bigger then I could get at those settings, but as it is I can not see them or get to them.
Okay was able to resize it by adding the following to my userChrome.css file:
#MailPreferences {
 width: 60em !important;
}

Found info on how to resize it here:
http://forums.mozillazine.org/viewtopic.php?f=39&t=2956439
(In reply to jsherk from comment #6)
> Can the preferences window be set so that it is resizeable? If I could
> resize it bigger then I could get at those settings, but as it is I can not
> see them or get to them.
No, you can't.
But you could toggle the preference "mail.preferences.inContent" from "false" to "true" in the config editor in order to open Thunderbird "Preferences" in a new tab.

This bug could be a duplicate of Bug 1155545 which has been patched for version TB 38.
I no longer use the above mentioned #MailPreferences tweak in my userChrome.css file and cannot reproduce your issue in TB 45 on an iMac 20".
(In reply to jsherk from comment #5)
> No, the problem does not go away in safe-mode and is still there.

The 'font' dropdown menu seems unusually large. Do you have any custom fonts whose name would be very long?
My pref window does not show this issue, although french language is known to have longer strings than english.
Flags: needinfo?(jeff)
Yes there is one font with an extremely long name. Will attach screenshot.
Flags: needinfo?(jeff)
Attached image LongFontName.png
Screenshot of really long font name
Component: Untriaged → Preferences
Summary: Composition preference screen cut off → Composition / general pref panel cut off if the font dropdown box is very wide (due to an unusually long font name in the list)
It appears to be the reason why all buttons are shifted to the right and outside the panel.
Status: UNCONFIRMED → NEW
Ever confirmed: true
A similar problem is happening in the e-mail Compose window, first appearing in Thunderbird 45.0. I'm on Windows 7 with a single monitor. See the attached partial screenshot. There are three fonts that are "not installed" as circled in in the screenshot. Actually each font looks like a list of fonts, the sort of most specific (e.g. HelveticaNeue) to least specific (e.g. "san-serif") list you would specify in CSS.

The issue seems to have something to do with the fonts in the e-mail. When I compose a new e-mail, the only "not installed" font is "Helvetica, Arial, san-serif (not installed). But when I reply to e-mail from certain people, I pick up more "not installed" fonts as in the screenshot attached. 

This bug is more annoying than one would initially think because it forces one to make the Compose window unnaturally wide for reading or writing at a given font size in order to use the buttons to the right of the font pulldown.
See comment 13 for details related to this attachment
(In reply to Matthew Kidd from comment #13)
> A similar problem is happening in the e-mail Compose window, first appearing
> in Thunderbird 45.0. I'm on Windows 7 with a single monitor. See the
> attached partial screenshot. There are three fonts that are "not installed"
> as circled in in the screenshot. Actually each font looks like a list of
> fonts, the sort of most specific (e.g. HelveticaNeue) to least specific
> (e.g. "san-serif") list you would specify in CSS.
The problem looks similar but is really different. You should report a new bug for this issue. Thanks.
Yes, I can reproduce this on the Organo font as in the screenshot.
Assignee: nobody → acelists
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: Unspecified → All
Attached patch patch (obsolete) — Splinter Review
I touch all 3 font pickers (2 in prefs, 1 in compose panel).
The changes consolidate the menulists to this:
1. crop="center" - if the font name does not fit, add ellipsis (...) in the middle of it. I think similar fonts often differ at the end of the name (think XXX Sans, XXX Serif)
2. sizetopopup="none" - if the menulist is small, the menupopup may still be wider when needed so that the user can see longer part of font names when he is actually selecting them.
3. max-width:25em on the compose font picker was needed to cap it to some sane size. In the pref dialogs, the 2 pickers are capped by the dialog size via the flex=1 (of which I add one).

I haven't tested Seamonkey.

I got the Organo font from http://logomagazin.com/organo-font/ (as seen in the screenshot).
Attachment #8753028 - Flags: ui-review?(richard.marti)
Attachment #8753028 - Flags: review?(mozilla)
Attachment #8753028 - Flags: review?(iann_bugzilla)
(In reply to :aceman from comment #17)
> 2. sizetopopup="none" - if the menulist is small, the menupopup may still be
> wider when needed so that the user can see longer part of font names when he
> is actually selecting them.

But if the menupopup does not need to be wider than the menulist, it is the same width so the same state as we have before the patch. At least that was the behavour for me on Linux. Please try it out on other platforms.
OK, I installed the font from here http://logomagazin.com/organo-font/ on my Win 7 system.
It's full name according to Windows is: "Organo (colored version at: log Regular", or maybe Windows appends the "Regular" and that's not part of the name.
In the font indicator that gets truncated to "Organo (colored version at: log".
Most likely due to bug 1265186 seconds later, the font indicator shows "Organo (not installed)".

With this font installed the font indicator looks wider than usually, however, the
  Tools > Options, Composition, General, HTML font selector
looks OK and the panel has the same size as usually and nothing is cut off like in attachment 8746563 [details].

Now, I don't find this font particularly useful:
It doesn't work due to an M-C editor problem (bug 1265186) and it carries advertising in its name
 "colored version at: logomagazin.com/organo-font"
so I don't see that we should fix anything here.

That said, I'd like Richard's opinion, and then I can test the patch. As stated, the UI already works without the patch on Win 7, so I'm most likely not the most suitable reviewer. I'd suggest someone with Linux or a Mac. However, I'm happy apply the patch on Windows and tell you whether it's working.
OK, I applied the patch.
The composition font indicator is now narrower that I'm used to, perhaps due to the max-width: 25em;
And the Tools > Options, Composition, General, HTML font selector it's super-wide now.
I must say, I don't like those two changes, so I'd ui-r- them ;-)

Let's hear from Richard.
(In reply to Jorg K (PTO during summer, NI me) from comment #19)
> OK, I installed the font from here http://logomagazin.com/organo-font/ on my
> Win 7 system.
> It's full name according to Windows is: "Organo (colored version at: log
> Regular", or maybe Windows appends the "Regular" and that's not part of the
> name.
> In the font indicator that gets truncated to "Organo (colored version at:
> log".

Strange, in TB I see the name as "Organo (colored version at: logomagazin.com/organo-font)", on some occassions (with the patch) truncated with ... in the middle.

> Most likely due to bug 1265186 seconds later, the font indicator shows
> "Organo (not installed)".

I'll check this out.

> With this font installed the font indicator looks wider than usually,
> however, the
>   Tools > Options, Composition, General, HTML font selector
> looks OK and the panel has the same size as usually and nothing is cut off
> like in attachment 8746563 [details].

Strange, I do see the expanded contents and thus cut off buttons, as in that screenshot. Maybe you have the preferences dialog manually expanded in width? 

> Now, I don't find this font particularly useful:
> It doesn't work due to an M-C editor problem (bug 1265186) and it carries
> advertising in its name
>  "colored version at: logomagazin.com/organo-font"
> so I don't see that we should fix anything here.

I don't think we should care it is an advertisement (at least we could easily find where to download it from). Maybe there could be real fonts with such long names. Or can we find MS guidelines on font naming that would prohibit/discourage long font names?

> That said, I'd like Richard's opinion, and then I can test the patch. As
> stated, the UI already works without the patch on Win 7, so I'm most likely
> not the most suitable reviewer. I'd suggest someone with Linux or a Mac.
> However, I'm happy apply the patch on Windows and tell you whether it's
> working.

On Linux the UI didn't work and the bug is reported on Mac. maybe Win 7 already has some max-width rules in the theme.
(In reply to Jorg K (PTO during summer, NI me) from comment #20)
> OK, I applied the patch.
> The composition font indicator is now narrower that I'm used to, perhaps due
> to the max-width: 25em;

Yes, we can discuss that size. I just made up some that appeared wider than the current state on Linux. Maybe em is not the right unit to use here. It is just proof of concept and Paenglab will flesh out the real size.

> And the Tools > Options, Composition, General, HTML font selector it's
> super-wide now.
Yes, it is not increased due to the flex. But it is not wider than in Display > Formatting > Default font. They are at least consistent now. Does the other one not bother you?
(In reply to :aceman from comment #21)
> Strange, I do see the expanded contents and thus cut off buttons, as in that
> screenshot. Maybe you have the preferences dialog manually expanded in
> width? 
I'm not aware of an option to change the size of the panel, so no.

> On Linux the UI didn't work and the bug is reported on Mac. maybe Win 7
> already has some max-width rules in the theme.
You've gotta love cross-platform ;-)

(In reply to :aceman from comment #22)
> Yes, it is not increased due to the flex. But it is not wider than in
> Display > Formatting > Default font. They are at least consistent now. Does
> the other one not bother you?
OK, I take back the ui-r- then ;-) Yes, it would be consistent. But on the compose window I need it a little wider (as mentioned and as per your reply "proof of concept").

The interesting thing here is why Win 7 tells me the font is called "Organo (colored version at: log Regular".
In OpenOffice I get "Organo (colored version at: log".

That's 31 characters and that seems to be a Windows limit:
https://www.google.com.au/?gws_rd=ssl#q=windows+font+name+length+31
(In reply to Jorg K (PTO during summer, NI me) from comment #23)
> (In reply to :aceman from comment #21)
> > Strange, I do see the expanded contents and thus cut off buttons, as in that
> > screenshot. Maybe you have the preferences dialog manually expanded in
> > width? 
> I'm not aware of an option to change the size of the panel, so no.

I can see on Win XP too that it is not resizable. I think on Linux it is.

> The interesting thing here is why Win 7 tells me the font is called "Organo
> (colored version at: log Regular".
> In OpenOffice I get "Organo (colored version at: log".
> 
> That's 31 characters and that seems to be a Windows limit:
> https://www.google.com.au/?gws_rd=ssl#q=windows+font+name+length+31

So maybe the creator of the font is on Mac and doesn't know about the limit :) Also Mac and Linux do not seem to have the limit.
Comment on attachment 8753028 [details] [diff] [review]
patch

Your patch doesn't apply for suite/themes/classic/messenger/messengercompose/messengercompose.css. Tried on Linux and Windows.

I'll give a ui-r- because first on Linux you gave all menulists in composer the max-width: 25em;. This makes the #msgIdentity shorter than the window. Why haven't you used the #FormatToolbar menulist { max-width: 25em; } you added on OS X and Windows?

Second, yes the menulist in prefs dialog is way too wide, especially when no font with long name is installed. Maybe when both menulists (font and size) don't overlap the restore button and still have visually a vertical gap to it, it could look better. And if where is a font with longer name, then also use the crop="center". But when the font names are shorter than the menulist, let the popup be as wide as the menulist. I'll attach a screenshot with short font names which looks not good.
Attachment #8753028 - Flags: ui-review?(richard.marti) → ui-review-
Attached image fontlist.png (obsolete) —
Screenshot showing the small popup with the wide menulist.
(In reply to Richard Marti (:Paenglab) from comment #25)
> Second, yes the menulist in prefs dialog is way too wide, 
But the "Options > Display, Formatting, Default font" is super-wide, too.
(In reply to Jorg K (PTO during summer, NI me) from comment #27)
> (In reply to Richard Marti (:Paenglab) from comment #25)
> > Second, yes the menulist in prefs dialog is way too wide, 
> But the "Options > Display, Formatting, Default font" is super-wide, too.

Correct. And this menulist's popup is as wide as the menulist. That's why I wrote, make them as wide as to the Restore button (I hope you know what I mean).
Comment on attachment 8753028 [details] [diff] [review]
patch

I got it now. With Aceman's patch they are both wide, bug one has a narrow drop-down. I'm clearing the r? for now.
Attachment #8753028 - Flags: review?(mozilla)
(In reply to Richard Marti (:Paenglab) from comment #26)
> Created attachment 8753410 [details]
> fontlist.png
> 
> Screenshot showing the small popup with the wide menulist.

Strange, I wrote that it doesn't happen, but it does, even for me now.
Attached patch patch v2 (obsolete) — Splinter Review
Please try this one.
Attachment #8753028 - Attachment is obsolete: true
Attachment #8753028 - Flags: review?(iann_bugzilla)
Attachment #8753554 - Flags: feedback?(richard.marti)
I tried it.
"Tools > Options, Composition, General, HTML font" is wide and so is the drop-down.

In the composition window the font indicator is wider than with the first version of the patch despite there still being this limit.

There is still the
+#FontFaceSelect {
+  max-width: 25em;
+}

So I don't know whether this limit kicks in and it would even be wider without it. Therefore I changed that to 525em and 12em and that had no effect. The width was always 250px.

I noticed that in the previous patch that read:
menulist {
+  max-width: 25em;
+#FormatToolbar menulist {

So I like "Tools > Options, Composition, General, HTML font", but the font indicator is a little too wide for my taste. And the CSS has no effect, so it doesn't seem to be right.
(In reply to Jorg K (PTO during summer, NI me) from comment #32)
> There is still the
> +#FontFaceSelect {
> +  max-width: 25em;
> +}
Yes, that is part of the fix.

> 
> So I don't know whether this limit kicks in and it would even be wider
> without it. Therefore I changed that to 525em and 12em and that had no
> effect. The width was always 250px.

Maybe because on Windows the font name is cut of at 31 chars so it never will be wider than 250px?

But try constructing an email with a font declaration wider than that (like <font face="font1,font2,font3...."> in which no font is installed. That may not be cut off by Windows, but will be shortened by the max-width declaration.

> 
> I noticed that in the previous patch that read:
> menulist {
> +  max-width: 25em;
> +#FormatToolbar menulist {

This declaration does not affect the Options dialog you mention later on. So what do you mean to say?

> So I like "Tools > Options, Composition, General, HTML font", but the font
> indicator is a little too wide for my taste. And the CSS has no effect, so
> it doesn't seem to be right.

Yes, there is no changed css in the Options dialog. The menulist fills the entire width of the dialog due to the flex="1". The sizetopopup property controls, whether the popup that expands from the menulist must be equal in width to the menulist itself, or it can be wider or narrower. Or even if it forces the menulist to widen to accomodate all possible value in the popup. But the docs do not seem to be clear to me as which value does what. So we just need to test it experimentally. Previous patch used value of "none". Now we try "pref".
Sorry I wasn't clear. Also, I had my ThunderHTMLedit add-on installed which forces the size of the font indicator to 250px, hence the confusion. Now with this disabled, I'm revisiting this.

There are two changes here:

1) "Tools > Options, Composition, General, HTML font".
I'm fine with that.

2) Width of the font indicator.
This CSS
+#FontFaceSelect {
+  max-width: 25em;
+}
is fine, too.

I tried with a very long font name conglomerate and the box widens to 300px. The ... are in the middle, so that's nice, too. Minor nit: In the drop-down, the ... are at the end, I'll attach a screen shot. So that's inconsistent. Maybe it would be possible to have only the drop-down/popup wider, but then again, to documentation says it's not possible:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/menulist
  If the menu has a maximum width, the popup will also be this width.

So maybe the patch is OK as it is, or maybe we want to make the max-width wider or address any of my suggestions from the previous paragraph.
Attachment #8748771 - Attachment is obsolete: true
Attachment #8753410 - Attachment is obsolete: true
Wider popup/drop-down menu with "none":

  <menulist id="FontFaceSelect"
            class="toolbar-focustarget"
            oncommand="doStatefulCommand('cmd_fontFace', event.target.value)"
            crop="center"
            sizetopopup="none"> <====
Comment on attachment 8753554 [details] [diff] [review]
patch v2

Already better. Please could you try to add a <spacer flex="1"> after the size menulist and give the font menulist a flex="2"? Then we would have the free space above the Reset button.

The popup in composer is a problem like Jörg shown. Doesn't exist a option to give the popup the minimal width of the menulist but let it be wider when needed?

(In reply to Jorg K (PTO during summer, NI me) from comment #35)
> Created attachment 8753877 [details]
> I like it better this way.
> 
> Wider popup/drop-down menu with "none":
> 
>   <menulist id="FontFaceSelect"
>             class="toolbar-focustarget"
>             oncommand="doStatefulCommand('cmd_fontFace', event.target.value)"
>             crop="center"
>             sizetopopup="none"> <====

This makes the popup smaller again when the font names are shorter than the menulist.
Attachment #8753554 - Flags: feedback?(richard.marti) → feedback+
(In reply to Richard Marti (:Paenglab) from comment #36)
> > Wider popup/drop-down menu with "none":
> > 
> >   <menulist id="FontFaceSelect"
> >             class="toolbar-focustarget"
> >             oncommand="doStatefulCommand('cmd_fontFace', event.target.value)"
> >             crop="center"
> >             sizetopopup="none"> <====
> 
> This makes the popup smaller again when the font names are shorter than the
> menulist.

Yes, but the font indicator doesn't have a minimum size so it's not so bad as in the preference selector. It starts off at 95px wide and grows as fonts with longer names are selected. The popup never looks drastically too narrow as in your attachment 8753410 [details]. Try it, "none" looks good here ;-)
(In reply to Jorg K (PTO during summer, NI me) from comment #37)
> Yes, but the font indicator doesn't have a minimum size so it's not so bad
> as in the preference selector. It starts off at 95px wide and grows as fonts
> with longer names are selected. The popup never looks drastically too narrow
> as in your attachment 8753410 [details]. Try it, "none" looks good here ;-)

Ah yes, this is true. Not thought this way.
Attached patch patch v3 (obsolete) — Splinter Review
Attachment #8753554 - Attachment is obsolete: true
Comment on attachment 8755950 [details] [diff] [review]
patch v3

The menulist in the Composition pref looks good now for me. ui-r=me
Attachment #8755950 - Flags: ui-review+
Comment on attachment 8755950 [details] [diff] [review]
patch v3

Thanks.
Attachment #8755950 - Flags: review?(mozilla)
Comment on attachment 8755950 [details] [diff] [review]
patch v3

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

Did I miss the r? ;-)

Sorry about the picky questions, I'm just trying to hide the fact that I'm not at my desk and can only try it out tomorrow.

Overall, this looks like r+, but give me 24 hours to try it.

::: editor/ui/composer/content/editorOverlay.xul
@@ +1066,5 @@
>               observes="cmd_renderedHTMLEnabler">
>    <menulist id="FontFaceSelect"
>              class="toolbar-focustarget"
> +            crop="center"
> +            sizetopopup="none">

Good ;-)

::: mail/components/preferences/compose.xul
@@ +120,5 @@
>              <caption label="&htmlComposeHeader.label;"/>
>              <hbox align="center">
>                <label control="FontSelect" value="&font.label;" accesskey="&font.accesskey;"/>
> +              <menulist id="FontSelect" preference="msgcompose.font_face"
> +                        sizetopopup="pref" crop="center" flex="2">

Can you explain what flex="2" does as compared to flex="1".

@@ +143,5 @@
>                    <menuitem value="x-large" label="&size-extraLargeCmd.label;"/>
>                    <menuitem value="xx-large" label="&size-hugeCmd.label;"/>
>                  </menupopup>
>                </menulist>
> +              <spacer flex="1"/>

And this?

::: mail/themes/linux/mail/compose/messengercompose.css
@@ +496,5 @@
>    background-image: url("chrome://messenger/skin/messengercompose/linux-noise.png");
>  }
>  
> +#FontFaceSelect {
> +  max-width: 25em;

So we settled for em as the correct unit?
(In reply to Jorg K (PTO during summer, NI me) from comment #42)
> Did I miss the r? ;-)
Wires crossed.
(In reply to Jorg K (PTO during summer, NI me) from comment #42)
> Can you explain what flex="2" does as compared to flex="1".

If there is free/unallocated space in the box (layout box), the element with flex=2 will expand to eat that space 2 times more than the element with flex=1.
Attachment #8755950 - Flags: review?(iann_bugzilla)
Comment on attachment 8755950 [details] [diff] [review]
patch v3

I guess Ratty can review this minimal change to suite/ faster ;-)
Attachment #8755950 - Flags: review?(iann_bugzilla) → review?(philip.chee)
Comment on attachment 8755950 [details] [diff] [review]
patch v3

> +++ b/editor/ui/composer/content/editorOverlay.xul

>    <menulist id="FontFaceSelect"
>              class="toolbar-focustarget"
> -            crop="right">
> +            crop="center"
> +            sizetopopup="none">

Please retain crop=right
[apparently we should use crop=end instead nowadays for RTL compat]
Then in function createFontFaceMenuitem() add:

  itemNode.setAttribute("tooltiptext", aFontLabel);

Bonus points for adding CSS text-overflow: ellipsis; in appropriate places.

(In reply to Richard Marti (:Paenglab) from comment #45)
> em is okay. em is relative to the font size and better to use in this case
> than px.

I would suggest using "ch" unless you can convince me that em is better.

(In reply to Jorg K (PTO during summer, NI me) from comment #50)
> I guess Ratty can review this minimal change to suite/ faster ;-)
r+ for the Suite changes.
Attachment #8755950 - Flags: ui-review-
Attachment #8755950 - Flags: review?(philip.chee)
Attachment #8755950 - Flags: review+
> Bonus points for adding CSS text-overflow: ellipsis; in appropriate places.
Double bonus points for showing the tooltip only if the menuitem is overflowed.
(In reply to Philip Chee from comment #51)
> > +++ b/editor/ui/composer/content/editorOverlay.xul
> 
> >    <menulist id="FontFaceSelect"
> >              class="toolbar-focustarget"
> > -            crop="right">
> > +            crop="center"
> > +            sizetopopup="none">
> 
> Please retain crop=right

Why? My reasoning for "center" was that we can then distinguish fonts likes "longFontName Narrow", "longFontName Bold" if the ellipsis is in the middle. The end of the string is useful to see.

> [apparently we should use crop=end instead nowadays for RTL compat]
> Then in function createFontFaceMenuitem() add:
> 
>   itemNode.setAttribute("tooltiptext", aFontLabel);

Good idea, but why is it needed? For me the full font name is shown on mouse-over even without that code. Probably added automatically by the menupopup code.

> Bonus points for adding CSS text-overflow: ellipsis; in appropriate places.

Why? Isn't the 'crop' attribute itself doing the cropping and ellipsis?

> 
> (In reply to Richard Marti (:Paenglab) from comment #45)
> > em is okay. em is relative to the font size and better to use in this case
> > than px.
> 
> I would suggest using "ch" unless you can convince me that em is better.

Why "ch" (size of character "0"). In that case, maybe "ex" is better?
Comment on attachment 8755950 [details] [diff] [review]
patch v3

r+ under one condition:
Please confirm that 25em is the right unit to use. Perhaps Richard can confirm.
Tested it. Looks good and works. Thanks!

As for my questions:
I read up on the flex stuff myself, no need to answer it.
Besides, that's what Richard asked for in comment #36.
Attachment #8755950 - Flags: review?(mozilla) → review+
em is okay. em is relative to the font size and better to use in this case than px.
(In reply to Richard Marti (:Paenglab) from comment #45)
> em is okay. em is relative to the font size and better to use in this case
> than px.

Thanks. Do you also agree with 25 or is there a better size?
25em is good for me.
(In reply to :aceman from comment #53)
> > [apparently we should use crop=end instead nowadays for RTL compat]
> > Then in function createFontFaceMenuitem() add:
> > 
> >   itemNode.setAttribute("tooltiptext", aFontLabel);
> 
> Good idea, but why is it needed? For me the full font name is shown on
> mouse-over even without that code. Probably added automatically by the
> menupopup code.

I'll add this. I found I had tooltips already (and even font previews directly in the menupopup) due to Jorg's extension I have installed in TB45 :)
(In reply to :aceman from comment #53)
> Why "ch" (size of character "0"). In that case, maybe "ex" is better?

"em" is a general measure for the font's size, whereas "ch" seems to better distinguish narrow from wide fonts as it represents the width only. I've asked the same question until I ran into a machine which was using a very narrow desktop font and the "em" measures resulted in disproportionately wide dimensions. According to https://developer.mozilla.org/en-US/docs/Web/CSS/length#Units "ex" is the corresponding height measure (height of the "x" letter).
>> Bonus points for adding CSS text-overflow: ellipsis; in appropriate places.
> Why? Isn't the 'crop' attribute itself doing the cropping and ellipsis?
Oops. Good point! Please ignore this point.
Can we finish this off since bug 1273438 is waiting for it ;-)
Attached patch patch v4Splinter Review
Unfortunately the previous version didn't, work the flex 1 and 2 made the menulist jump in size depending on which font was selected.
Also the sizetopopup="none" made the menupopup smaller than the menulist width when no long font was present. That was ugly too.
Attachment #8755950 - Attachment is obsolete: true
Attachment #8760086 - Flags: ui-review?(richard.marti)
Attachment #8760086 - Flags: review?(philip.chee)
Attachment #8760086 - Flags: review?(mozilla)
Well, you've basically gone back to v2 of the patch with s/25em/31ch/:
https://bugzilla.mozilla.org/attachment.cgi?oldid=8753554&action=interdiff&newid=8760086&headers=1

You can have my r+, but I'll let the others opine first.
Comment on attachment 8760086 [details] [diff] [review]
patch v4

I'm not 100% happy with the wide font menulist in the prefs but we have no other solution, so ui-r+

For the #FontFaceSelect could you use max-width: 35ch; ? 31 is okay for a text field but the menulist has also padding and a dropdown arrow which also uses space and makes usable spce smaller than the 31ch.
Attachment #8760086 - Flags: ui-review?(richard.marti) → ui-review+
Attachment #8760086 - Flags: review?(philip.chee) → review+
https://hg.mozilla.org/comm-central/rev/d5d61eac1a5a7a6349f9157a51a814a80b18d200
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 50.0
You need to log in before you can comment on or make changes to this bug.