21177 - <input> text field without "type=text" is too wide

Status: VERIFIED FIXED

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

Description

[Akkana Peck]

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.

Comment 1

[buster]

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.

Comment 2

[Akkana Peck]

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.

Comment 3

[sujay]

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

Comment 4

[buster]

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?

Comment 5

[Akkana Peck]

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?

Comment 6

[Akkana Peck]

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

Comment 7

[buster]

marking Linux-only.

Comment 8

[Akkana Peck]

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.

Comment 9

[buster]

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;

Comment 10

[Akkana Peck]

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.

Comment 11

[Akkana Peck]

Attachment: Small test case

Comment 12

[buster]

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.

Comment 13

[Akkana Peck]

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.

Comment 14

[Hixie (not reading bugmail)]

Changing summary to match bug description.

The problem may well be in html.css.

Comment 15

[Akkana Peck]

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.

Comment 16

[Vladimir Ermakov]

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