1278127 - The font picker in Thunderbird's compose window has font names needlessly indented

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[:aceman]

The id=FontFaceSelect menulist in the compose window has a menupopup with font names available. On Linux, these font names are indented, but there is no icon or checkmark preceding the names that would use the space. On Windows they are not indented. On OS X there supposedly is a checkmark showing which font is being used.

I think either remove the indent or use it for a checkmark also on linux.

Comment 1

[Richard Marti (:Paenglab)]

Attachment: bug1278127.patch

First I tried to hide the .menu-iconic-left for all class="noIconPopup" popups, but the folderpane-mode-selector-menulist shows a radio button on Linux. So I had to hide them only for the #FontFacePopup.

Comment 2

[:aceman]

(In reply to Richard Marti (:Paenglab) from comment #1)
> First I tried to hide the .menu-iconic-left for all class="noIconPopup"
> popups, but the folderpane-mode-selector-menulist shows a radio button on
> Linux.

Then why is it marked noIconPopup if it has "icons" (needs space for the radio marker) ?

Comment 3

[Richard Marti (:Paenglab)]

Because the menuitem[type="radio"] isn't defined on Windows like on Linux
https://dxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/linux/global/menu.css#179
and is empty.

Comment 4

[:aceman]

Seems to also be the case for #viewPicker. On Linux it has bullet before the chosen item, in Windows there is none (even no space). But in the submenus of e.g. Format menu in Compose window, there are bullets even on Windows. Is there some rule to that? That menus can have bullets, but menupopups can't?

Can you see on OS X/Linux if the useRadios attribute on FontFacePopup is set to true? On Windows it is false.

Comment 5

[Richard Marti (:Paenglab)]

Attachment: bug1278127.patch v2

Removed a not used selector.

Comment 6

[Richard Marti (:Paenglab)]

Attachment: bug1278127.patch v2.1

Same patch as v2 but applied on top of bug 1268520. Depending when the other bug lands this or the other patch are valid.

Comment 7

[:aceman]

Comment on attachment 8760401 [details] [diff] [review]
bug1278127.patch v2.1

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

Thanks. I will land this with 31ch changed to 35ch as requested in the other bug.

Comment 8

[:aceman]

https://hg.mozilla.org/comm-central/rev/7f87bea3b1e86129ac84b72e4ba31c46a06327e6