Reproduce: 1. Set pref in fonts panel to sans-serif 2. View this bug in Mozilla Actual result: The page is (correctly) rendered in a sans-serif font, but the (drop-down) widgets are in a serif font. The font also looks too large. Expected result: Widgets either honor the serif/sans-seirf pref, or always use sans-serf (which is common for widgets).

They should either use the same font as the surrounding text, or use the CSS2 UI font (which is usually sans-serif, but not always).

Sending to Layout. I think that someone in Layout owns the css for html content.

Um, ok. Changing to HTML Form Controls, which it should be. CCing Ian, who owns html.css.

Re-assigning six bugs from Clayton's list to Harish for further triage...

Eric, any idea to whom this bug should be directed to?

Triaging Clayton's list: --------------------------- Rod, you mentioned something very similar to this bug in the raptor meeting? Could you please take a look at it? Thanx

*** This bug has been marked as a duplicate of 53744 ***

No, this is no dup. The other bug was Win only, while I see this on Linux. The other bugs is about font sizes and sans-serif vs. monospace, this one about serif vs. sans-serif. REOPENing.

So is the point here that on Linux it is two fonts size too large and it is using serif instead of sans-serif?

The latter. I never said anything about sizes.

Marking nsbeta3- since we are past nsbeta3

BenB: "The font also looks too large." Looks like you were speaking about sizes to me... What is the system UI font on your system? Is it serif? For the widgets we should now be using the system UI font not the font in the preferences.

Size: Oh, yes, you're right. I'm sorry. I don't know what you mean with system UI font. My GTK uses a sans-serif font, if you mean that. The buttons in the Mozilla chrome observe my serif/sans-serif pref. Textedits and dropdowns in the chrome are always sans-serif. Dropdowns in webpages are always serif.

The problem is that when Pierre made his checkin he switched the default font for buttons and selects to "serif" and for it to be as large as the default size, where on Windows we knock the default size down by two. here is the current code: #ifdef XP_UNIX switch (sysID) { case eSystemAttr_Font_Field: font->mFont.name.AssignWithConversion("monospace"); font->mFont.size = defaultFixedFont.size; break; case eSystemAttr_Font_Button: case eSystemAttr_Font_List: font->mFont.name.AssignWithConversion("serif"); font->mFont.size = defaultFont.size; break; } #endif Here is what I propose we do: #ifdef XP_UNIX switch (sysID) { case eSystemAttr_Font_Field: font->mFont.name.AssignWithConversion("monospace"); font->mFont.size = defaultFixedFont.size; break; case eSystemAttr_Font_Button: case eSystemAttr_Font_List: font->mFont.name.AssignWithConversion("sans-serif"); PR_MAX(defaultFont.size - NSIntPointsToTwips(2), 0); break; } #endif If you think this is correct, we can mark it a dup of bug 53744 and I can check this fix in when I fix the Windows problem.

Widgets use San Serif on Window, on Linux widgets use Serif fonts. On linux the branch displays the proper Serif font for widget.

> Linux widgets use Serif fonts Nonsense. I havn't seen this yet. All widgetset I've seen use sans-serif.

Look at 4.x and then look at mozilla you will see they are same. I went to bugzilla query page.

No Serif font in widgets.

OK, 4.x honors my preference of the variable width content font. We should either do the same, or, if failing with this, use a sans-serif font, which is usually used for widgets (in chrome), on all platforms and toolkits I know (at least as default).

On Redhat 6.2 install, Netscape 4.74, no previous profile, it shows Serif fonts. I will try to get an image.

waqar, sure it does, Times is the default for variable width fonts in content in 4.x Linux. You don't need to attach an image, it will be similar to the last one attached. That does mean that you should lock me to that font family.

Ok, I see what you want, then we should change the summary field to say some thing like "Content widget should use font specified in browser prefs". So basically the change would be to get the font name from the prefs and use that for all the content widgets.

waqar, we have 3 possibilities, see the initial description and Matthew's comment.

Problem still present in Mac build 2001011912, Mac OS 9.0. Steps to reproduce: * View this bug report. Expected results: * Buttons and single-line text fields should use the `caption' font (e.g. Charcoal 12). * Multi-line text fields should use the `monospace' font (e.g. Courier New 12). * Popup menus and listboxes should use the `menu' font (e.g. Charcoal 12). Actual results: * Buttons use the `serif' font (e.g. Georgia 14). * Single-line text fields use the `monospace' font (e.g. Courier New 12). * Multi-line text fields use the `monospace' font (e.g. Courier New 12). * Popup menus and listboxes use the `monospace' font (e.g. Courier New 12).

This bug (and a couple of other bugs with the appearance of form controls) could probably be fixed by incorporating the following changes into mozilla/layout/html/document/src/forms.css. Note that I haven't tried applying these changes myself.

Setting milestone to future for now. Rod, if you can fix this easily we'll try and get it in for mozilla0.9.1

*** Bug 70797 has been marked as a duplicate of this bug. ***

Currently, forms.css is specifying `field', `list', and `button' fonts for text fields, menus and listboxes, and buttons respectively. The trouble is, these fonts don't exist. For some people (like Ben) they are falling through to serif or monospace, and for others (like me) they are falling through to sans-serif. Either way they look like crud, because they're not using the same font as native controls on the user's platform (or controls in the user's chosen theme, for that matter). This patch fixes forms.css to use the `caption' and `menu' fonts defined in CSS which reflect the user's system settings, the same fonts which both Modern and Classic themes use for chrome. It also applies the `caption' font to the LABEL element, to make it clear that any part of a control's label can be clicked rather than mousing exactly over the control itself; this will make users faster at dealing with Web forms as they have an obviously bigger target to aim at. Finally, the patch implements the standard practice of using progressively smaller system fonts for controls inside FIELDSETs (see, for example, the Preferences window or the View Options window in the Mac Finder). I can see no way to do this without using a descendant selector; but since very few Web pages use LABEL or LEGEND in the first place, the performance hit should be miniscule in comparison with (for example) the descendant seletors used in html.css for getting the correct bullet style in nested lists. Review, anyone?

*** Bug 80596 has been marked as a duplicate of this bug. ***

ignore the first patch i created, i didn't use -u so it looks cranky.

r=choess (Linux)

r=imajes (Windows)

>Currently, forms.css is specifying `field', `list', and `button' fonts for text >fields, menus and listboxes, and buttons respectively. The trouble is, these >fonts don't exist. Um, why don't these fonts exist? Or, more appropriate maybe, why are we using them if they don't exist?

Rod S. sent me this via email: _________________________________________________________________________________ Whoa! No, no, no, no, no (whew, that had to be said.....) Of coarse those fonts don't exist. Those fonts are CSS fonts that are then mapped to the underlying native fonts. If there is a problem on a specific platform where the current `field', `list', and `button' font do not look right or are not mapped to what we perceive is the right font, then we change where these fonts get mapped from CSS fonts to native fonts. Starting looking at the code here: http://lxr.mozilla.org/mozilla/source/content/base/src/nsRuleNode.cpp#1698 I don't have a strong opinion about legend or label, but the others should NOT change. So summarize for me on what platforms do what fonts look bad? Rod

Apparently, forms look bad on every platform except Windows. `field', `list', and `button' are *not* CSS fonts (though they have been proposed for CSS3), but Rod wants us to keep using them. Giving them a -moz- prefix should be filed as a separate bug. So, here's a description of what needs to be done (as far as I can tell): 1. http://lxr.mozilla.org/mozilla/source/gfx/src/mac/ nsDeviceContextMac.cpp#278 needs to be changed to use the correct kThemeWhatever fonts instead of using sans-serif. This is also covered in bug 71539. 2. The block around http://lxr.mozilla.org/mozilla/source/content/base/src/nsRuleNode.cpp#1708 should probably be removed. There's no reason for this to be different in Quirks Mode; MSIE and other Mac browsers make no such distinction. 3. Similarly, the Quirks block starting at http://lxr.mozilla.org/mozilla/source/content/base/src/nsRuleNode.cpp#1775 should be removed. This appears to be what is causing the serif ickiness on Linux.

The spec doesn't go through any debate about these fonts. Renaming them to '- moz' is not a priority. Otherwise what you are saying is that we should get rid of the compatibility with Nav4 because that's what these hacks are for. We had strong reasons to keep the same appearance as previous Netscape browsers. I don't know if they are still valid. We seem to go more often with what the market is nowadays. Rod?

There is another underlying problem with not using the font specified for the page in form controls that I think people are missing here. I realize OS/2 is a little font crippled, but bear with me here. I set my OS/2 to use a font for Japanese that I know can render Japanese. I go to www.yahoo.co.jp. The button does not display correctly because it is using my systems button font which does not know how to do Japanese. I told Mozilla to use a specific font for Japanese. It should use that font for ALL Japanese INCLUDING form controls. At the bare minimum, this should be a preference.

ARGH. This problem is getting worse on OS/2. Form controls on pages should NOT use operating system fonts! They should use webpage fonts. What if the OS font happens to be a bitmap font that doesn't scale? Why was this change made to forms.css? These lines should be REMOVED.

*** Bug 124164 has been marked as a duplicate of this bug. ***

OK, why is this marked Future if it has a Mozilla 1.0 keyword. This really needs to be fixed. Controls on Web pages should use the web page font. All references to platform fonts in forms.css should be removed!

Bug 124164 is about a perfectly selected font not being giving sufficient vertical input field height to display, not about improper font selection. How can it be a duplicate of this bug?

*** Bug 125432 has been marked as a duplicate of this bug. ***

Michael, if you don't want form controls to use chrome fonts, then you shouldn't want this bug to be fixed. Currently Mozilla *doesn't* use chrome fonts for form controls, and that is a major contributing factor to Mozilla's form controls looking like crap. Pierre, it's not true that the current behavior is compatible with Nav4. Nav4 used your `Monospace' setting for single-line text fields, which was ugly; Seamonkey uses sans-serif, which is worse. Nav4 used your `Proportional' seeting for buttons and option menus, which was ugly; Seamonkey uses sans- serif, which is worse. I still don't understand why forms.css is using the `field' system font when `field' isn't in CSS, hasn't been implemented in Mozilla, and looks terrible. Using `caption', as attachment 56448 [details] [diff] [review] did, and as MSIE for Mac and Opera for Mac do, would be much nicer.

Monospace in Nav4 makes it usable, which is preferable to pretty when both are not possible simultaneously. I find serif fonts so objectionable, I remove them from my system. I never want to see serif fonts on a PC screen.

This bug indirectly blocks #84271 which is an nsbeta1+ bug so it can not have TFV: Future (which it got assigned 2/28/2001). Please give this bug some lovin'.

Below is the code for Linux and Mac. Please tell me specifically what you want done to either of these sections of code or attach a patch and I will get it checked in. Here is the current Linux code: #if defined(XP_UNIX) && !defined(XP_MACOSX) if (eCompatibility_NavQuirks == mode) { switch (sysID) { case eSystemFont_Field: aFont->mFont.name.Assign(NS_LITERAL_STRING("monospace")); aFont->mSize = defaultFixedFont->size; break; case eSystemFont_Button: case eSystemFont_List: aFont->mFont.name.Assign(NS_LITERAL_STRING("serif")); aFont->mSize = defaultVariableFont->size; break; default: NS_ERROR("unexpected SID"); } } #endif Here is the Mac specific code: #if defined(XP_MAC) || defined(XP_MACOSX) if (eCompatibility_NavQuirks == mode) { switch (sysID) { case eSystemFont_Field: case eSystemFont_List: aFont->mFont.name.Assign(NS_LITERAL_STRING("monospace")); aFont->mSize = defaultFixedFont->size; break; case eSystemFont_Button: aFont->mFont.name.Assign(NS_LITERAL_STRING("serif")); aFont->mSize = defaultVariableFont->size; break; } } #endif

Is there any way to use the web page font rather than hardcoding serif, sans-serif or some other font?

Bulk moving all nsbeta1 nominations to Moz1.1. If the nomination is approved it will be marked nsbeta1+ and moved to the Mozilla1.0 milestone.

Marking nsbeta1-. Please remove the - after a clear explanation of what really needs to be done has been added to this bug. This bug seems to have morphed from its original definition into at least 3 different issues: HTML form controls should honor user pref's settings for fonts The Mac needs different default fonts for HTML form controls The HTML form controls should honor fonts set int the web page. Lets pick one issue for this bug and file separate bugs for the other issues.

Bug 130632 filed on the fact that on Mac the "field" font is unconditionally mapped to "sans-serif". Bug 130635 filed on the fact that on Linux the "field" font seems to sometimes get mapped to "sans-serif". Bug 130637 filed on the fact that none of the nice code from comment 53 is ever executed.

Actually, the code in 53 is executed if you have set this pref set: layout.forms.use_standard_or_quirks I've been continuing to look at this on OS/2 and resigned my self to the fact that the best way to fix this is to have platform specific forms.css files. If I remove any reference to font: field, list, button in forms.css, OS/2 fonts work as I want. As I matter of fact, they work better than Windows as far as I am concerned because this page: http://www.kaply.com/work/efs.html displays correctly. I added a code change into nsRuleNode to try to help the OS/2 situation, but it doesn't work as well as I'd hoped. So my suggestion is platform specific forms.css files. I don't see what else can be done.

Bug 67749 is about platform specific forms.css files?

From the related bug 25657: James Lariviere wrote: > mozilla uses a fixed font for > textareas while everything else is proportional. Seems reasonable that > textareas should use the same font as the other controls. And, just to be clear, this should surely default to monospaced (so that the WIDTH attribute of TEXT TYPE="INPUT" actually has any useful function in HTML at all), and only become proportional/variable width IF the page author manually codes it that way. Right?

I should have been more specific. That pref is never set in any .js file in the tree, so currently we never execute that code.

Also, we have platform-forms.css now.

Platforms can decide their own font using platform-forms.css. If there is a specific bug on a specific platform at this point in time, it should be opened up against that platform.