Build ID: 1999110508 Platform: Windows NT To reproduce: - Launch the browser - Load the URL above - Click into the first text input control Result: The font changes from a proportional to a fixed-width font. Expected result: I'm not 100% sure but I believe we should always display the contents of text input controls using fixed-width fonts, right?

Reassigning to Kevin.

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

This occurs with any text field (<input type=text>) which already contains text, for instance the Bugzilla forms like this one. cpratt: I'm not sure if we _should_ be using a fixed-pitch font, actually. I know NN4 does, but IE uses a proportional sans-serif font, and frankly it looks better. In a TEXTAREA we should indeed be using a fixed pitch font, though, because they have multiple lines. This isn't a standards-based thing, though, so I don't mind either way...

Re-assigning to buster.

setting this to M15 and assigning to kin for review.

Accepting bug.

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

Changing platform to all. Steve says this is an easy fix, a little fiddling with CSS.

reassigning to rods, who already fixed this out of the goodness of his heart. thanks, rod! he has the fix for content area already, and is minutes away from the fix in xul controls.

the font is now correct for input type=text - fixed

I updated today at about 9:30, and I still see the same problem. I've also tried updating layout/html/document/src/html.css, but it didn't help. Reopening.

I'm also seeing the font change with a Win32 build pulled at around 9am today. You can only see the font change when you have Gfx Scrollbars activated.

I was doing my test with GFX off, but now I have them turned on I dont't see it for a simple input type=text. If you are talking about the URL bar then it isn't my bug. I tried to find it in the XUL code and got lost.

This is now just a problem for the URLBar with GFX scrollbars turned on. assigning to Eric.

Clearing FIXED resolution due to reopen.

QA Contact update.

p4 for m14

This is still happening on text input fields (eg on this form) on Linux build 2000.01.08.08.

This also happens for text widgets if you change the font style for input[type= text] in html.css. The font is properly picked up in widgets before they get focus, but after focussing, they revert to some font that is specified elsewhere.

putting on beta1 radar

Thinking this was a problem fixable within html.css, I changed font-family of input and input[type=text] from -mox-fixed to sans-serif. After loading this very page, all text controls had a proportional font. Clicking into each of the controls changed the font back to a fixed font, demonstrating that this bug still persists. But you all knew that anyway. Well, tinkering with html.css got me nowhere... The problem seemed to be in the code. After searching for some keywords, I narrowed down the problem to these lines of code: http://lxr.mozilla.org/seamonkey/source/editor/base/nsHTMLEditor.cpp#3468 The comment above it along with the source line is: 3466 // Make sure we have fixed-width font. This should be done for us, 3467 // but it isn't, see bug 22502:, so we have to add "font: monospace;". 3468 styleValue.Append("font-family: monospace; "); I don't have enough HDD space for recompilation, so I just edited ender.dll to say "font-family: sans-serif;" instead of "monospace; " above. After restarint Mozilla, clicking into -moz-fixed text boxes changed their font from fixed to sans-serif. So, the lines above are causing this trouble. They mention bug 22502 which is marked as fixed, with these lines apparently being the fix. Due to my current inability to download anything over 50mbs on my computer, I can't try recompiling Mozilla w/o those lines and seeing whether the bug surfaces, but I hope that at least this information helps.

I tried commenting out those editor lines last week when I was working with Hangas on text field fonts, and it didn't affect the changing font. Also, note that text fields/areas in chrome, text fields/areas in content, the plaintext editor, and plaintext mail compose all have different fonts, yet they're all going through this editor monospace line. I still don't think we should have to force the font family in the editor, but we were told by layout to do it this way: see buster's comments in bug 22502. Though perhaps we should be doing that inside the "if (aWrapColumn > 0)" clause; that would be trivial to do, but changing that doesn't seem to affect text field fonts as far as I've noticed.

This is still happening, and is now much more apparent because the window font has been changed.

I'm seeing it on Linux, too, as of this morning (it used to be rare on linux). I made a change yesterday to the editor plaintext rules (only force monospace font if wrapping is on) but that doesn't seem to be causing this: backing my change out had no effect, and I didn't see any font changing in my precheckin test, so I think the culprit is some other change that happened last night.

I can fix this with this patch: Index: nsFormControlHelper.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/forms/src/nsFormControlHelper.cpp,v retrieving revision 1.43 diff -w -c -1 -r1.43 nsFormControlHelper.cpp *** nsFormControlHelper.cpp 2000/02/24 12:51:25 1.43 --- nsFormControlHelper.cpp 2000/03/16 20:51:31 *************** *** 621,623 **** case NS_FORM_INPUT_PASSWORD: ! aFont = &styleFont->mFixedFont; break; --- 621,624 ---- case NS_FORM_INPUT_PASSWORD: ! // aFont = &styleFont->mFixedFont; ! aFont = &styleFont->mFont; break; Since style resolution should correctly fill in mFont to be fixed-width for HTML text inputs. However, this change might break the nav quirks compatibility mode; if we are in eCompatibility_Standard, then we use mFont and return earlier in this function. Someone who understands the compatibility mode stuff needs to look at this. My guess is that in nav quirks mode, we want to return mFixedFont for HTML text inputs, and mFont for XUL inputs.

Yes, that seems to be the fix. I tested it out. I think that is the right thing to do.

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

This code has been around since at least 11/18/1998 (version 1.1 of nsFormControlFrame.cpp), so it was probably carried over from the days of native widgets, when it didn't matter what the font was set to. I'll check in Simon's fix.

(just an argument) *the font of the form field should be whatever it is set to in CSS or the form field is not properly stylable and we may as well give up and go home* 'nuff said. ;)

This fix makes it so, I believe.

Eric, I checked in the fix.

Thanks Rod!

Updating QA contact.

verified build 2001081303 & 2001081308 os:win95,linux7.1,mac8.6