See summary. Look at the URL location bar, or any text input field in a dialog. The use a monospace font, but should use a sans serif font.

This is very true, but there is some kind of a bug in the html:input widget that is using a different font than the one specified in the skin. Pierre: I am sending this to you since you have another bug that sounds related to this one. I hope that you are the correct person for this. The html:input should use the font set in the css file, it seems to use a completely different font, and possibly a different size.

The size can be set through the font-size property but the font family is overridden by a hard-coded style rule called PlaintextInitalStyle in nsTextEditRules.cpp. It means that all the text input fields in the application are in monospace font. Changed Component, reassigned to buster and CCd akkana.

reassigning to jfrancis, setting to M14

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

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

accepting bug

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

Personally, I much prefer monospace for input controls since there are some letters that are hard to distinguish using sans-serif fonts (esp. 1liI|). I think one reason computer code often is done in monospace fonts even when printed inline.

I did what pierre suggested below in the nsTextEditorRules - fixed

My fixed worked great except for the default case where type isn't specified and it creates a text field. This is still the correct solution but someone needs to fix the default case first.

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

when fixing this bug, pleaes verify that the problem reported in 2357 is fixed as well.

should this be assigned to rods?

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

ok, I'll bite. I don't understand the communication mechanism between the document inside the editor, and the document that contains the editor. I'd read the source but I don't even know where to look. How is it that the font family is communicated to the editor? What is the problem rod mentions with the "default" case? I understand the editor is blasting over the font info and we don't want that. What I don't understand is how to tell if I am in the "default" case (don't even know what that means), where presumably, the editor has to specify the font family itself. Any pointers appreciated.

Joe: the "default case" rod mentions is this: <input> vs. <input type="text"> These are equivalent in many ways, but not identical. Pierre and Rod are working together to rationalize this. The end goal is for the editor to *not know and not care* at all about presentation fonts for text controls. Having font-setting code in the editor is wrong. Style sheet control, and proper propogation of that style from the text control frame to the embedded subdocument, is the right way to go. I don't understand why this is assigned to Joe. Rod and Pierre have been having conversations about how to fix this. So I'm assigning this back to Pierre so he and Rod can hammer out the solution. Rod knows what code to add to the UA style sheet, and what code to remove from the editor to get rid of the hard coded font style. But my understanding is that he cannot do this until Pierre fixes a problem related to the missing type="text", as Rod discusses in his comment "Additional Comments From rods@netscape.com 1999-12-23 12:11"

Adding Joe back on cc list because it's a rules issue and he might be interested in following it. The plaintext edit rules have to be able to set a style on the body that specify the wrap style (pre, pre wrap, moz pre, etc.) Something then has to be able to figure out (either from that, or from context of where it is in what window) what the font style should be. I don't have any particular feeling that the font should be set from the plaintext edit rules (I'm not even sure whose idea that was), but in any case that doesn't seem to be working since the urlbar, text fields, and text areas are all plaintext editors but they all have different fonts. So it looks like there's already a style rule overriding whatever the editor sets (but maybe not in all cases). Incidentally, Rods' fix didn't work for the url bar either, but navigator.xul does specify type=text for the urlbar (at least, it does now, but perhaps it didn't back then).

I have a fix for the problem with the 'font-family: -moz-fixed' rule which can't be overriden. Reassigned to Rods.

Note. When verifying this bug make sure that bug 22926 is also fixed. This can be checked by clicking on the text field on this page: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/widgets/01.html ...and ensuring that the background does not go white (i.e., remains transparent as it is before focusing).

Fixed

Yesss! Thank you, thank you!

I still don't see the edit fields in the URL bar and other places in the chrome using a sans-serif font.

Ok, given the summary of this bug I was wrong to mark it fix. Now that we can set the font on text fields, what specification says that all the textfields in the UI are sans-serif?

I am going to reassign this to hangas now that the internal machinery works.

Clearing FIXED resolution due to reopen.

I don't know whether there's a spec, but the sans-serif font used in 4.x on Linux is better looking, just as readable, and much narrower (so much more can fit on a page) than the serif font used in mozilla. You need a 650-pixel width to view the entire Description field in the bugzilla Enter Bug page with mozilla, whereas with 4.x it's not a limiting factor (it's smaller than the 600-pixel mozilla banner).

Oops, I was confusing width and height. You actually need a width of 846 pixels to show the entire Description field in mozilla. Will attach screen shots.

In your 4.x preferences, what's your "Fixed Width Font"? Mine is Courier, and I see a monospace font in all textareas. And I like it that way. (For me, the limiting width factor in a bugzilla bug is the three columns of fields at the top.)

You're right -- I must have changed my font preferences. My fixed-width font is Clean (Schumacher), which probably was my choice rather than the default. (And yes, it still is fixed width -- but it's relatively narrow compared to Courier, and IMHO much better looking, but of course I understand that's a matter of taste.) I have no idea what our official policy is on the right fixed-width font to use for text fields/areas. Adding German to cc list.

Well, I tried changing my text input font by editing html.css to change the font- family for input[type=text]. But then bug 18232 bit me; before focussing the widget, the font is fine; after focussing, it reverts to -moz-fixed.

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

Unable to fix this bug before 24390 is fixed.

Bumping to M15 :-(

Did you mean to mark this fixed?

Oops. No this is not fixed. Thanks!! Sheesh, bring on the weekend!

Sending to our UI owner.

this appears to have been fixed. thanks, smfr!

Verified fixed in latest build