Go to the Bugzilla Enter Bug page (see URL). Notice the text fields for URL and Summary are much wider than they should be (the src specifies only 60 columns) and don't fit in the window (if they do, resize the window to where they don't). This is semi-dogfood because of bug 21176 -- makes it hard to use bugzilla -- but if it didn't scroll, it wouldn't be such a problem.

I don't see this on windows. It looks identical to Nav 4.x sizing. Is this linux-only? The only thing that I know that could effect text control sizing differently on different platforms is text measurement.

Yes, it seems to be linux-only. Pavlov points out that if measurement of font width was broken, we'd likely be seeing a lot more problems than we are. Is it possible that a different font is being measured to determine the width of the text field than the one that's actually being displayed in the end, or that some assumption is being made about the font used or its size? The width difference between the actual size of the text field and the size of 60 characters in the font actually used is nearly a factor of two.

changing platform/OS to all...I see this problem on all three platforms using 12/10 build. Also notice the email and passwd fields to get into Bugzilla(the page prior) are too wide also...

sujay, akkana: sujay changed platform to all, but I'm simply not seeing this on WinNT. Are you still seeing this on Windows? on Linux?

I'm definitely still seeing it on Linux (it's a major pain to use dogfood to file new bugs because of 21176, the horizontal scroll jumping around). I haven't tried it recently on Windows (my NT box seems to have locked up over the holidays, haven't gotten it back on track yet). I am not seeing the problem on Mac using a build from just before Christmas. Sujay, do you still see it on all three?

I just checked Mac M12 and a current Windows build, and I don't see it in either place. Linux only.

marking Linux-only.

Some specific data: the "Reassign bug to" text field on this bugzilla screen (specified in the source as (SIZE=32) is shown by mozilla on my Linux box as 56 characters wide; 4.61 on the same machine shows it at exactly 32 characters wide. "Bugs that bug 21177 depends on" (size not specified in the source) is rendered by mozilla as 35 characters wide; 4.61 shows it as 20 characters wide. All text fields seem to be similarly enlarged. Perhaps we're not correctly measuring the width of the fixed-width font we use for text fields. It may be system dependant; I noticed on Kin's Linux machine (an ancient RH5.1 install) the other day that his text fields were fairly normal widths.

cc-ing pierre, who might (?) own font measurement code now. Also cc-ing erik, who is my second guess. akkana, is there anywhere else in the system where we seem to be measuring the default fixed-width font incorrectly? Can you build a little test page that displays fixed-width font text and compare that to it's display in 4.x? I think you'll need to specify font-family: -moz-fixed;

Ask and ye shall receive. I've pinned this down to a minimal case (see URL field for this bug; I'll also attach it for the benefit of those outside the firewall). It turns out that bugzilla text fields look like this: <INPUT NAME="assigned_to" SIZE=10> (no type=text). If I add type=text, then the size is correctly calculated. font-family: moz-fixed in normal text is calculated fine (at least, it wraps at the right place) and things like tables and forms don't affect the results at all. The second field (the input name=...) uses a different font from the fixed one, and sizes itself wide enough to hold 17 characters even though the source specifies 10; the first field (input type=text) sizes itself correctly.

When you say the second text control "uses a different font from the fixed one", you mean that on Linux you see a different font in the second one? Because the HTML doesn't change the font at all. If I understand you correctly, that says the problem is that somehow, on Linux only, the style system is picking a different default font for text controls of the form: <input> compared to <input type="text"> This sounds like the problem that's holding up Rod from checking in his fixes for being able to set the font of a text control (and remove the evil hard coded value in the editor.) I suspect the fix for bug 17303 will fix this also, or at least enable the fix. Adding 17303 as a dependent bug, but not a duplicate. Moving to M14 because 17303 is set to M14. If you want this fixed sooner, you'll have to work with pierre and rod to get that bug fixed sooner.

Yes, I mean that I see a different font on linux, because the style system is picking it up form somewhere. I've asked Beth to bring this up with Rick and Pierre and try to get 17303 addressed in M13, because this is a major usability problem for dogfood on Linux. I'm happy to help in any way I can to get this fixed asap.

Changing summary to match bug description. The problem may well be in html.css.

The fix for 17303 fixed this problem -- now the bugzilla text fields are the correct size. Yeehaw! Taking the liberty of marking this fixed to get it off Steve's radar.

Verified on -Windows 98 build 2000-09-20-05-M18 -Linux RedHat6.2 build 2000-09-19-21-M18