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.

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

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.

Setting all current Open/Normal to M4.

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.

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

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

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

Marking M5

Redistributing to M8...

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

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.

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

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

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

Didn't make M8

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.

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

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.

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.

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)

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