238962 - Menus have stopped using consistent font

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Sam Little]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7b) Gecko/20040325
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7b) Gecko/20040325

For some reason, what in Java are "Menu" objects and non-static "MenuItem"
objects use a different display font from fixed "MenuItem" objects. This may be
related to specifying custom fonts or perhaps from using a profile imported from
(and shared in) v1.6


Reproducible: Always
Steps to Reproduce:
1. 
2.
3.

Comment 1

[Sam Little]

Attachment: captured sample of mixed fonts in menus

Comment 2

[R.K.Aa.]

Have you fonts defined in userChrome.css?

Comment 3

[Felix Miata]

Attachment: screenshot of OS/2 1.7b with no userChrome.css, no Innotek ft2lib

WFM

Comment 4

[Felix Miata]

Attachment: screenshot of OS/2 1.7b with userChrome.css, no Innotek ft2lib

Results of my userChrome.css:

statusbar {font-size: 7pt !important;} /* statusbar */
toolbar {font-size: 9pt !important;} /* urlbar text */
.treecol-text {font-size: 8pt !important;} /* mailnews column headings */
treechildren {font-size: 9pt !important;} /* mailnews folder & header panes */

/* Kill icons on normal bookmarks */
toolbarbutton.bookmark-item:not(.bookmark-group):not([type="menu"])
> .toolbarbutton-icon {
	display: none;}

toolbar {min-height:16px;}

toolbarbutton.bookmark-item {
	margin-left: 1px !important;
	margin-right: 1px !important;
    font-size: 8pt !important;
    font-family; 'trebuchet ms' !important;
    font-weight: normal !important;
    min-height:18px;}

.bookmark-item {
  max-width: 55ex !important;
  font-weight: normal !important;
  font-family: 'trebuchet ms' !important;
  font-size: 9pt !important;}

/* Kill normal bookmark icons in the bookmarks menu */
menuitem.bookmark-item > .menu-iconic-left {
	display: none;}

/* Kill only default tabbrowser icons (no site icon) */
.tabbrowser-tabs *|tab:not([image]) .tab-icon {
	display: none;}

.tabbrowser-tabs .tab-text {font-size: 8pt !important; font-weight: normal;} /*
tab text */

tab, tabpanels {padding: 1px; !important;}

toolbargrippy {display: none !important;}

#nav-bar-inner {margin: 0px !important;}

Comment 5

[Felix Miata]

Attachment: screenshot of OS/2 1.7b with userChrome.css and Innotek ft2lib

Innotek beautifies.

Comment 6

[Felix Miata]

To clarify, Sam's screenshot shows menu category fonts (css menu) in what
appears to be arial 10pt at normal stroke weight, while showing individual menu
items (css menuitem) in warpsans at normal stroke weight. Warpsans is available
only in 9pt (shown in attachment 144944 [details]) and 7pt. The OS/2 defaults for both are
warpsans bold, which is the OS/2 systemwide default font for menus, shown in
attachment 144980 [details].

Sam, if you haven't done anything with userChrome.css, you might want to try
this to fix it: close Mozilla, delete XUL.mfl, restart.

Comment 7

[Felix Miata]

Attachment: OS/2 1.7b classic w/ 10pt trebuchet system menu, ft2lib, but no userChrome.css

Comment 8

[Sam Little]

I deleted XUL.mfl and have no userChrome.css file. The behavior persists,
whether ft2lib.dll is around or not.

Comment 9

[Felix Miata]

Is it the same with a brand new profile? Attachment 144991 [details] was made with a
virgin profile.

Comment 10

[Sam Little]

Creating a new profile shifted the font selections to serif fonts, but they were
still different.

Comment 11

[Mike Kaply [:mkaply]]

Are you using any enhancers? HAve you modified any fonts in your oeprating system?

Comment 12

[Felix Miata]

Attachment: attachment 144944 emulation via userChrome.css

menubar menu .menubar-text,
menupopup menu,
menupopup menu .menu-iconic-text,
toolbar,
toolbarbutton
 {font-family: arial; font-size: 9pt;}

menupopup menu
 {font-size: 9pt !important;}

menupopup menuitem {font-family: warpsans !important; font-size: 9pt;}

(my system is set to use 10pt Trebuchet for menus and window icon labels)

Comment 13

[Sam Little]

No to the latter, and I don't think so for the former.  Either way, this is
different behavior from 1.7alpha and 1.6....

Comment 14

[Sam Little]

Attachment: font load log created using test gfx_os2.dll

Executed per MKaply's instructions.

Comment 15

[Sam Little]

Attachment: font log created using test gfx_os2.dll

Created per MKaply's instructions. 2nd try; file type slipped. Note: uploaded
as binary due to one (1) high-bit character in log.

Comment 16

[Mike Kaply [:mkaply]]

Interesting. 

Looking at the log, it looks like we got a bad extra character on WarpSans which
is causing the font not to match...

Comment 17

[Mike Kaply [:mkaply]]

One more logging DLL to try:

http://www.kaply.com/work/gfx_os2.dll

Same procedure.

I think this should give us the info we need.

Comment 18

[Sam Little]

Attachment: font0413.log

Font log run using 2004-04-13 debug version of gfx_os2.dll.

Comment 19

[Sam Little]

Incidentally, I have a vague recollection of a problem elsewhere a couple of
years ago with the WarpSans font name gaining extraneous characters and causing
problems. I've searched my Compuserve message archives and can't find it there,
but I'm still researching....

Comment 20

[Mike Kaply [:mkaply]]

Attachment: First attempt at a patch

For some reason, the font data in this persons INI file is in binary.

Solution is to use PrfQueryProfileData - this grabs string and binary data.

Comment 21

[Mike Kaply [:mkaply]]

Attachment: Final patch

Commented per Javier's explicit instructions.

Comment 22

[jhp (no longer active)]

Comment on attachment 146057 [details] [diff] [review]
Final patch

- Rather than check if fontName[0] == '\0', you should probably check if
PrfQueryProfileData returned FALSE.
- The second comment in the patch should reference PrfQueryProfileData, not
...String.
- You said that data in the INI file is written with a leading LENGTH
indicator.  Does PrfQueryProfileData take care of truncating the output to this
length, or do we need to take care of it?

Comment 23

[Mike Kaply [:mkaply]]

Yep FALSE is better. I'll do that.

Interesting comment I Found:

his function is handy for retrieving previously stored data about a program. If
this API call returns FALSE, it will not touch pBuffer. Therefore, you may
initialize a structure to a default configuration.

Although in this case, I don't think that makes sense since we would be doing a
lot of work to setup a failure case that might not happen.

As far as your third comment goes, that length of the data is handled internally
in OS/2, so we don't have to worry about it. We get the right string with the
right length.

Comment 24

[Mike Kaply [:mkaply]]

Attachment: Final final patch

Javier's comments addressed

Comment 25

[Mike Kaply [:mkaply]]

Fix checked in.

Comment 26

[Sam Little]

Though it seems improved, I'm not seeing this fixed in the dynamic menu content.
Specifically:
  - File -> [Work Offline]
  - View -> Show/Hide -> Everything except "Site Navigation Bar"
  - View -> Text Zoom -> Everything except "Smaller" and "Larger"
  - View -> Character Encoding -> all codes below the separator
  - View -> Everything except "Get New Themes"
  - Go -> Everything below "History"
  - Bookmarks -> Everything below "Manage Bookmarks"
  - Tools -> Cookie Manager -> Everything except "Manage Stored Cookies"
  - Tools -> Image Manager -> Everything except "Manage Image Permissions"
  - Window -> Everything
  - Debug -> Leak Detector -> [Verbose]

Comment 27

[Mike Kaply [:mkaply]]

Honestly, I'm tempted to mark this as invalid.

The data that is in your OS/2 INI file is invalid, and I don't know how it got
there.

Is this a straight 1.7rc1 with a new profile that has the problem?

Comment 28

[Sam Little]

Well... as soon as I find the CSS setting to change them back, I won't care. :)
I'd also fix OS2.INI if I could figure out how, but the problem doesn't manifest
in RegEdit2 and I never got any of the other INI browsers. Either way, I can't
find any matches to the strings printed in the logs generated by the Mozilla
tests in my OS2.INI file.

Hmmm... more interesting is that, over the same browser session, the fixed
<menuitem>s have changed from WarpSans to Arial, but nested <menu>s haven't.

Comment 29

[Mike Kaply [:mkaply]]

Are you using FT2LIB?

Comment 30

[Sam Little]

At the moment, yes. I'd hidden ft2lib.dll before without any difference in how
menus appear under 1.7b; I'll give it a try with 1.7rc1 when I get a chance.

Comment 31

[Mike Kaply [:mkaply]]

Could you post the output from:

www.kaply.com/work/showfonts.exe

Thanks

Comment 32

[Mike Kaply [:mkaply]]

Argh.

I have to null terminate after PrfQueryProfileData. New fix coming.

Comment 33

[Mike Kaply [:mkaply]]

Attachment: Final final final patch

OK, I have it now. I actually changed the fonts on my system to have this bug
so I could recreate it :)

Sorry for the hassle.

PrfQueryProfileData tells us how much data we got back, so we then null
terminate.

Comment 34

[jhp (no longer active)]

Comment on attachment 147046 [details] [diff] [review]
Final final final patch

I would make the success case (got a fontname and need to null terminate) come
right after PrfQueryProfileData, and the failing case be the 'else' case. 
Otherwise, r=pedemonte

Comment 35

[Mike Kaply [:mkaply]]

Comment on attachment 147046 [details] [diff] [review]
Final final final patch

sr=blizzard (platform specific)
a=mkaply (OS/2 only)

Comment 36

[Mike Kaply [:mkaply]]

I definitely fixed it this time.

I changed my INI files to look like Scott's so I could see the problem and I
verified that it is fixed.