18232 - [form]Clicking inside a text input control changes font used

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P4)

Description

[cpratt]

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?

Comment 1

[karnaze (gone)]

Reassigning to Kevin.

Comment 2

[cpratt]

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

Comment 3

[Hixie (not reading bugmail)]

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...

Comment 4

[Kevin McCluskey (gone)]

Re-assigning to buster.

Comment 5

[rubydoo123]

setting this to M15 and assigning to kin for review.

Comment 6

[kinmoz]

Accepting bug.

Comment 7

[Kathleen :Brade]

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

Comment 8

[Akkana Peck]

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

Comment 9

[buster]

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.

Comment 10

[rods (gone)]

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

Comment 11

[Akkana Peck]

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.

Comment 12

[kinmoz]

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.

Comment 13

[rods (gone)]

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.

Comment 14

[rods (gone)]

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

Comment 15

[leger]

Clearing FIXED resolution due to reopen.

Comment 16

[gerardok]

QA Contact update.

Comment 17

[Peter Trudelle]

p4 for m14

Comment 18

[Richard Zach]

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

Comment 19

[Simon Fraser [no longer active]]

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.

Comment 20

[Peter Trudelle]

putting on beta1 radar

Comment 21

[Oleg Rekutin]

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.

Comment 22

[Akkana Peck]

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.

Comment 23

[Simon Fraser [no longer active]]

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

Comment 24

[Akkana Peck]

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.

Comment 25

[Simon Fraser [no longer active]]

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.

Comment 26

[rods (gone)]

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

Comment 27

[rods (gone)]

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

Comment 28

[Eric Pollmann]

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.

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

(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.

;)

Comment 30

[Simon Fraser [no longer active]]

This fix makes it so, I believe.

Comment 31

[rods (gone)]

Eric, I checked in the fix.

Comment 32

[Eric Pollmann]

Thanks Rod!

Comment 33

[bsharma]

Updating QA contact.

Comment 34

[jerone]

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