78526 - [FIX]text in form controls has become too small under strict mode

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[James Lariviere]

Over the past week the default monospace font size used in JUST strict mode has
become smaller (too small in my opinion) for textarea, input[type="text"], etc.
for form controls.  I need a magnifying glass to read damn text in forms.

I will post up a screenshot comparing last weeks nighly to current (5-1-04 win
build) on a site I work on (url field).

Comment 1

[James Lariviere]

Attachment: screenshot showing the differences in font size between win builds

Comment 2

[rods (gone)]

I fixed Bug 64331 so the nsDeviceContextWin no longer added 2 point sizes to the 
font when it got it's system properties. The logFontHieght
can come back negative in some instances and the rounding was incorrect. 

I did a lot of testing, but forgot to test it in Strict mode. 

In nsCSStyleRule.cpp (ages ago) Pierre added the platform specific ifdefs when 
we are in quirks mode to use the appropriate font name and
font size. 

Since I have now fixed a kludge in nsDeviceContextWin.cpp the font for a "Field" 
is now 2 point sizes too small, but if we were to use the
default size, but NOT the name, for Strict mode it works again. 

Comment 3

[James Lariviere]

Then, this should be an easy fix. Good. :-)

THanks rod.

Comment 4

[rods (gone)]

Attachment: patch

Comment 5

[rods (gone)]

Ignore this last patch....

Comment 6

[rods (gone)]

Attachment: final patch

Comment 7

[Kevin McCluskey (gone)]

With the latest patch installed, I have a few questions.
For the eSystemAttr_Font_Field: in strict mode the font size is reduced 2 point
sizes, but for NavQuirks it isn't.

for both eSystemAttr_Font_Button, eSystemAttr_Font_List the font is size is
always reduced by 2 points regardless of whether its strict or NavQuirks?

Is this correct?.  If it is please add a comment to the code to explain why the
size is reduced in at all and why it only needs to be reduced for
eSystemAttr_Font_Field.



   switch (sysID) {
            case eSystemAttr_Font_Field:
              if (eCompatibility_NavQuirks == mode) {
                font->mFont.name.AssignWithConversion("monospace");
                font->mFont.size = defaultFixedFont.size;
              } else {
                font->mFont.size = PR_MAX(defaultFont.size -
NSIntPointsToTwips(2), 0);
              }
              break;
            case eSystemAttr_Font_Button:
            case eSystemAttr_Font_List:
              if (eCompatibility_NavQuirks == mode) {
                font->mFont.name.AssignWithConversion("sans-serif");
              }
              font->mFont.size = PR_MAX(defaultFont.size -
NSIntPointsToTwips(2), 0);
              break;
          }

Comment 8

[rods (gone)]

For the text field the catch is that in NavQuirks we use a fixed font and 
therefore we use the default size as defined by the browser, which happens to be 
the correct point size. 

In strict mode, we now want to use a proportional font and so we use a point 
size as defined by the browser. Well, it wouldn't make any sense to use a 
proportional font and the "fixed" font size to get the correct results. So it 
means we need to use the "defaultFont" size which is a proportional font (and as 
it turns out we are then doing what we need to do for buttons) Which is use the 
default size - minus 2 points sizes because it is too large otherwise. 

For button and selects we always use the default size minus 2 points because 
when in NavQuirks or when using the system font it is always a proportional font 
and since we want to use a size that is defined by the browser, we once again 
use the defaultFont size and decrease it by 2 point sizes.

Also, note that for buttons and select the font difference between sans-serif 
and the system default which is "MS Sans Serif" is very minor, but still very 
important.

I will attach a new patch with a less verbose explanation.

Comment 9

[rods (gone)]

Attachment: patch with comments

Comment 10

[James Lariviere]

Rod, what does this need to get patched in?

Comment 11

[rods (gone)]

It's now up for review

Comment 12

[Kevin McCluskey (gone)]

r=[e-mail]

Comment 13

[Marc Attinasi]

sr=attinasi

Comment 14

[rods (gone)]

Attachment: patch moved from nsCSSStyleRull.cpp to nsRuleNode.cpp

Comment 15

[rods (gone)]

The patch is the same it has just moved files because og hyatt's rework of style 
resolution.

Comment 16

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

a=dbaron for trunk checkin (on behalf of drivers)... although I'm a little
concerned that we have to be messing with system fonts at this level (I would
think what happens in gfx ought to work in all cases).

Sorry this one fell through the cracks for a bit.

Comment 17

[rods (gone)]

I agree Pierre should have NEVER put the platform ifdefs in the code, I think I 
may already have filed a bug about removing them.

Comment 18

[rods (gone)]

fixed

Comment 19

[rods (gone)]

fixed, really...

Comment 20

[James Lariviere]

verf.

great now I can read form controls again without a microscope ;-).

win build 06-08-20