17303 - Text input fields in chrome should use sans serif font

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Michael Lowe]

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.

Comment 1

[hangas]

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.

Comment 2

[Pierre Saslawsky]

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.

Comment 3

[rubydoo123]

reassigning to jfrancis, setting to M14

Comment 4

[Pierre Saslawsky]

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

Comment 5

[Pierre Saslawsky]

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

Comment 6

[Joe Francis]

accepting bug

Comment 7

[Pierre Saslawsky]

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

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 9

[rods (gone)]

I did what pierre suggested below in the nsTextEditorRules - fixed

Comment 10

[rods (gone)]

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.

Comment 11

[buster]

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

Comment 12

[buster]

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

Comment 13

[buster]

should this be assigned to rods?

Comment 14

[Pierre Saslawsky]

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

Comment 15

[Joe Francis]

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.

Comment 16

[buster]

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 [e-mail]  1999-12-23 12:11"

Comment 17

[Akkana Peck]

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

Comment 18

[Pierre Saslawsky]

I have a fix for the problem with the 'font-family: -moz-fixed' rule which can't

be overriden.



Reassigned to Rods.

Comment 19

[Hixie (not reading bugmail)]

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

Comment 20

[rods (gone)]

Fixed

Comment 21

[Akkana Peck]

Yesss!  Thank you, thank you!

Comment 22

[Michael Lowe]

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

Comment 23

[rods (gone)]

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?

Comment 24

[rods (gone)]

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

Comment 25

[leger]

Clearing FIXED resolution due to reopen.

Comment 26

[Akkana Peck]

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

Comment 27

[Akkana Peck]

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.

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 29

[Akkana Peck]

Attachment: Screenshot from mozilla

Comment 30

[Akkana Peck]

Attachment: screenshot from 4.61

Comment 31

[Akkana Peck]

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.

Comment 32

[Simon Fraser [no longer active]]

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.

Comment 33

[Hixie (not reading bugmail)]

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

Comment 34

[hangas]

Unable to fix this bug before 24390 is fixed.

Comment 35

[hangas]

Bumping to M15  :-(

Comment 36

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Did you mean to mark this fixed?

Comment 37

[hangas]

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

Comment 38

[hangas]

Sending to our UI owner.

Comment 39

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

this appears to have been fixed. thanks, smfr!

Comment 40

[Michael Lowe]

Verified fixed in latest build

Comment 41

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/3683c13da339
[fenix] For https://github.com/mozilla-mobile/fenix/issues/17303: Move ext fun runIfFragmentIsAttached to utils