Closed
Bug 238962
Opened 21 years ago
Closed 21 years ago
Menus have stopped using consistent font
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: SGwylan, Assigned: mkaply)
Details
(Keywords: fixed1.7)
Attachments
(10 files, 3 obsolete files)
43.63 KB,
image/jpeg
|
Details | |
7.99 KB,
image/png
|
Details | |
8.61 KB,
image/png
|
Details | |
23.26 KB,
image/png
|
Details | |
31.46 KB,
image/png
|
Details | |
10.51 KB,
image/png
|
Details | |
1.31 KB,
application/octet-stream
|
Details | |
26.11 KB,
application/octet-stream
|
Details | |
5.58 KB,
patch
|
jhpedemonte
:
review+
|
Details | Diff | Splinter Review |
532 bytes,
patch
|
jhpedemonte
:
review+
mkaply
:
superreview+
mkaply
:
approval1.7+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•21 years ago
|
||
Comment 3•21 years ago
|
||
WFM
Comment 4•21 years ago
|
||
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•21 years ago
|
||
Innotek beautifies.
Updated•21 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Comment 6•21 years ago
|
||
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•21 years ago
|
||
Reporter | ||
Comment 8•21 years ago
|
||
I deleted XUL.mfl and have no userChrome.css file. The behavior persists,
whether ft2lib.dll is around or not.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 9•21 years ago
|
||
Is it the same with a brand new profile? Attachment 144991 [details] was made with a
virgin profile.
Reporter | ||
Comment 10•21 years ago
|
||
Creating a new profile shifted the font selections to serif fonts, but they were
still different.
Assignee | ||
Comment 11•21 years ago
|
||
Are you using any enhancers? HAve you modified any fonts in your oeprating system?
Comment 12•21 years ago
|
||
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)
Reporter | ||
Comment 13•21 years ago
|
||
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....
Reporter | ||
Comment 14•21 years ago
|
||
Executed per MKaply's instructions.
Reporter | ||
Comment 15•21 years ago
|
||
Created per MKaply's instructions. 2nd try; file type slipped. Note: uploaded
as binary due to one (1) high-bit character in log.
Attachment #145952 -
Attachment is obsolete: true
Assignee | ||
Comment 16•21 years ago
|
||
Interesting.
Looking at the log, it looks like we got a bad extra character on WarpSans which
is causing the font not to match...
Assignee | ||
Comment 17•21 years ago
|
||
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.
Reporter | ||
Comment 18•21 years ago
|
||
Font log run using 2004-04-13 debug version of gfx_os2.dll.
Reporter | ||
Comment 19•21 years ago
|
||
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....
Assignee | ||
Comment 20•21 years ago
|
||
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.
Assignee | ||
Comment 21•21 years ago
|
||
Commented per Javier's explicit instructions.
Assignee: general → mkaply
Attachment #146053 -
Attachment is obsolete: true
Status: UNCONFIRMED → ASSIGNED
Assignee | ||
Updated•21 years ago
|
Attachment #146057 -
Flags: review?(pedemont)
Comment 22•21 years ago
|
||
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?
Assignee | ||
Comment 23•21 years ago
|
||
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.
Assignee | ||
Comment 24•21 years ago
|
||
Javier's comments addressed
Attachment #146057 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #146057 -
Flags: review?(pedemont)
Assignee | ||
Updated•21 years ago
|
Attachment #146069 -
Flags: review?(pedemont)
Updated•21 years ago
|
Attachment #146069 -
Flags: review?(pedemont) → review+
Assignee | ||
Comment 25•21 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 21 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
Reporter | ||
Comment 26•21 years ago
|
||
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]
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Assignee | ||
Comment 27•21 years ago
|
||
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?
Reporter | ||
Comment 28•21 years ago
|
||
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.
Assignee | ||
Comment 29•21 years ago
|
||
Are you using FT2LIB?
Reporter | ||
Comment 30•21 years ago
|
||
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.
Assignee | ||
Comment 31•21 years ago
|
||
Could you post the output from:
www.kaply.com/work/showfonts.exe
Thanks
Assignee | ||
Comment 32•21 years ago
|
||
Argh.
I have to null terminate after PrfQueryProfileData. New fix coming.
Assignee | ||
Comment 33•21 years ago
|
||
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.
Assignee | ||
Updated•21 years ago
|
Attachment #147046 -
Attachment description: Fix → Final final final patch
Attachment #147046 -
Flags: review?(pedemont)
Comment 34•21 years ago
|
||
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
Attachment #147046 -
Flags: review?(pedemont) → review+
Assignee | ||
Comment 35•21 years ago
|
||
Comment on attachment 147046 [details] [diff] [review]
Final final final patch
sr=blizzard (platform specific)
a=mkaply (OS/2 only)
Attachment #147046 -
Flags: superreview+
Attachment #147046 -
Flags: approval1.7+
Assignee | ||
Comment 36•21 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•