2486 - Text inputs are one (or two) character(s) too wide

Status: VERIFIED FIXED

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

Description

[Richard Ekle]

The page appears to lay out correctly except for the fact that there is a large
empty gap to the right of everything.  This causes the horizontal scroll bar to
indicate that the page is a lot wider than it is.

Comment 1

[troy]

Chris, the problem is this:

<INPUT TYPE="text" SIZE="15" NAME="query">

You're making the INPUT element much larger than it should be and that causes
things to be too wide

Comment 2

[Richard Ekle]

It appears that the INPUT object is rendering too wide.  I'm not sure why
rendering this INPUT box a few characters too big would case the entire page to
think it's twice as big as it is supposed to be.

Comment 3

[leger]

Setting all current Open/Normal to M4.

Comment 4

[karnaze (gone)]

There are a couple of problems with the <INPUT TYPE="text" SIZE="15"
NAME="query">. First, we are using a larger font than Nav. You may have to get
assistance from Peter on this. Second, we inferred that Nav used the '%' char as
the basis of its char width calculations. Even in Nav the input text is smaller
than that; it is only 12 or 13 '%' chars in size.

As another observation, test8size.html (off of test 8) is showing some
discrepancies from Nav. For example our size=2 is larger than Nav's.

Comment 5

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 6

[Eric Pollmann]

Marked bug 1394 a dup of this.  Rod says:

"The issue is: the text control isn't getting set with the correct font and font
size."

and gives a test case of http://www.search.com

Comment 7

[Eric Pollmann]

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

Comment 8

[Eric Pollmann]

Marking M5

Comment 9

[Eric Pollmann]

Redistributing to M8...

Comment 10

[Eric Pollmann]

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

Comment 11

[Eric Pollmann]

Regarding the font size=2 issue that Chris mentioned above, there was an error
in the font size calculation formula in Nav that caused fonts to be too small in
many cases.  Somehow I managed to save a message from way back in the day when
we were using the old code base and this issue was discovered by Peter Linss:

http://blueviper/bugs/font/rounding

This may account for some of the discrepancies, but certainly not all of them.

Comment 12

[Hixie (not reading bugmail)]

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

Comment 13

[Hixie (not reading bugmail)]

(Note that in native-widgets mode, the widgets sport left and right margins of
around 1em in size, which is probably also affecting the calculations.)

Comment 14

[Hixie (not reading bugmail)]

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

Comment 15

[Eric Pollmann]

Didn't make M8

Comment 16

[Sean Richardson]

Attachment: Screencaps of INPUT elements for Moz M11 and Nav 4.7

Comment 17

[Sean Richardson]

Attachment: Simplified testcases for INPUT SIZE 4.x parity

Comment 18

[Sean Richardson]

Comments:

First, with Mozilla M11 build 1999101216 there is no evidence of the large
empty gap to the right of everything reported back in Jan/1999. In particular,
www.freshmeat.net displays well at all reasonable canvas widths.

Second, the INPUT controls appear to be almost exactly the same horizontal
size with M11 as with Nav 4.7. See the Screencaps attachment.

It looks like this one has been quashed since the spring, although
there are two minor issues left:
1. The SMALL INPUT used at freshmeat is rendered noticeably taller than the
   text inside it with Mozilla M11, compared to Nav 4.7. See the bottom
   part of the Screencap attachment. On the other hand, it may be Navigator
   that is in error here: see pollmann's comments about FONT SIZE=2
2. The INPUT controls are wide enough to hold one more character than their
   SIZE in both cases with Mozilla M11. Is this already noted as a distinct
   bug? I'll check.

Aside from those two issues, the problems described earlier in 1999 do not
appear now, so suggest resolving as WORKSFORME.

Comment 19

[Eric Pollmann]

Wow, is this bug really that old?!

Rod, you mentioned you were working on pixel/size issues trying to get Gecko to
emulate Nav.  The one outstanding issue in this bug is that the text input
fields are one character too wide.  Sorry for hoarding this bug for so long.. :)

Comment 20

[Sean Richardson]

Attachment: Inconsistencies: INPUT SIZE and FONT SIZE permutations

Comment 21

[Sean Richardson]

The new testcase (10/19/99) shows the appearance of INPUT form controls
in permutations of 3 sizes (10, 20, & 30) and the seven HTML 3.2 FONT sizes.

Conclusions:
1. There is a nonlinearity affecting both Mozilla and Communicator,
   whereby the largest, by FONT SIZE, INPUT controls hold at least one
   more character than the smallest.
2. In Communicator, all INPUT controls sized at less than the default
   FONT SIZE hold at least one less character than they should, by
   INPUT SIZE, and the largest hold about 1/2 character more.
3. Mozilla doesn't have that problem, just almost the same problem.
   The smallest INPUT CONTROLS (and normal-sized, too), by their FONT SIZE,
   hold one more character than they should, by their INPUT SIZE, and the
   largest hold almost two characters more than they should.
4. The odd behaviour at FONT SIZE="+3" is a distinct bug, and may be
   a valid testcase for another open bug about too-tall INPUTS.

Tested with:
Windows NT 4.0sp3, mozilla.exe, build 1999-10-18-08-M11
Windows NT 4.0sp3, netscape.exe, Communicator 4.7

Changed Summary to reflect the variation in overwidth.

Comment 22

[rods (gone)]

Ok, so I spent a lot of time figuring this all out and had a lot of help from
Peter L. We size the input text and textarea (IT, TA) differently for NavQuirks
and for Standard mode. I was able to locate the algorithms in the Nav source
code and we absolutely duplicate the calculations for a given font and font
metrics when Gecko is in NavQuirks. We use regular "leaf" content layout when in
Standard mode.

Now, there are two reasons why we may have different IT & TA sizes from Nav 4.x:
1) Peter was unable to exactly match Nav's fonts for every permeation (Nav does
some bizarre things) Although, I think we pretty much there.
2) Gecko fixes a rounding error in font calculations which causes certain fonts
at certain sizes to be sized different than Nav. After much discussion we
decided to fix this and differ from Nav.

Here is the code:
// round font size off to floor point size to be windows compatible
logFont->lfHeight = - NSToIntRound(rounded * app2dev);  // this is proper
(windows) rounding
//logFont->lfHeight = - LONG(rounded * app2dev);  // this floor rounding is to
make ours compatible with Nav 4.0

The commented line is the "old" incorrect way of rounding.

Now for Standard mode:
I looked at the the attachment test with viewer in Standard mode and viewer
sized them all correctly.  According to Peter all font sizing tests should
be run with: <font size=XXX> where xxx is 1-7, instead of using negative values.
The default font is 3, and the relative values are relative to 3, so -3 is zero
and this really isn't an appropriate value.

Summary:
Gecko is doing its best to match Navigator when in NavQuirks mode and any
differences we will have to live with. In Standard mode should should be doing
the right thing, i.e. showing the correct number of chars obeying style (margin,
padding, border).

So, I am going to close this bug out, if there are any sizing problem with IT or
TA in Standard mode I will gladly look at them and fix them, but currently we
will not be investing anymore effort in NavQuirks sizing.

Comment 23

[rods (gone)]

Oh, I forgot to mention that the reason +3 is so different, is +3 from the
default font is 6 (ok, so I can add) and the round off error mostly comes into
play with font sizes 2 and 6 (but it does somewhat depend on the font)

Comment 24

[Chris Petersen]

Based on Rod's comments, marking as verified fixed.