7543 - size attribute for text input tag handled inconsistently

Status: VERIFIED DUPLICATE of bug 25657

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

Description

[cpratt]

build id: 1999060208
platform: windows nt

at the Microsoft Expedia Web site, the input controls for the departing city &c.
are set to have a SIZE of 14. However, apprunner is drawing them much wider than
that (around 20 chars). Expected result is that no more than 14 characters can
be displayed in the field.

Comment 1

[karnaze (gone)]

Reassigning to Eric.

Comment 2

[webmaster]

Works fine on Windows NT 4.0 using viewer (6/28/99)... Exactly 14 "%"s fit in
the box (although in IE 5, only 9 fit. Bug on their part?)

Comment 3

[cpratt]

Viewer is pretty much dead at this point; please use apprunner.exe to verify
problems. Using the 15.6.99 build under Windows 95, apprunner still exhibits the
problem (to reproduce, start typing into the 'Leaving from' field; you should
only be able to fit 14 chars into it, but it accepts about 20). Reopning,
clearing resolution.

Comment 4

[Eric Pollmann]

Attachment: Minimzed test case

Comment 5

[Eric Pollmann]

This is doubless a widget set bug.
I've tested in viewer and runner:

  Linux viewer: 17.3
  Linux apprunner: 12.75
  NT 4.0 viewer: 14
  NT 4.0 apprunner: 10

Since GFX will be coming in and changing things soon, I'm marking this M15 to
indicate it's much lowered priority.

Comment 6

[Antti Näyhä]

Verified the attachment as a valid test case for the bug. (The document is not
100% valid HTML, but Mozilla should be able to render it OK anyway.)

After testing the following builds/platforms...
- 1999071417 Apprunner on Windows NT 4.0 SP4
- 1999071417 Viewer on Windows NT 4.0 SP4
- M7 Apprunner on Windows NT 4.0 SP4

...I don't believe this is a bug.  The number of characters that fit on a text
INPUT field varies because some browsers (eg. Nav4, Mozilla viewer) use a
fixed-pitch font, while others (eg. IE4, Mozilla apprunner) use a proportional
font.  Neither is wrong and both are correct.

If a proportional font is used, the 'size' attribute value cannot be accurate.
For example: when viewing the attached test case on the 1999071417 Apprunner,
the input field can display over 40 lowercase 'l' letters, while it can only
display 8 uppercase 'W's.

I think that the current interpretation of the 'size' attribute value in
Apprunner is a totally acceptable average for a proportional font.  Maybe the
behaviour has been changed since this bug was reported?

Marking resolved/invalid - please reopen if you disagree (or if you think it
should be resolved/fixed instead).

Comment 7

[cpratt]

Yes, I disagree. It's important that we work correctly with MSN. Reopening.

Comment 8

[Antti Näyhä]

OK, I further investigated the problem, and I'm attaching a second test case
which demonstrates the problem using several different font families for the
INPUT element.

There's actually one problem which is clearly a bug: Test 5 on the page fits 15
characters, when it should only fit 14.

Another thing is that when using a proportional font, we're currently using a
bit larger average value for character width than IE.  Compare eg. the rendering
of test 4 on IE and Apprunner and you'll see the difference.  As stated before,
this is not a bug in Mozilla, but I guess we want to be consistent with IE on
this.

(Test 2 reveals a font-family bug in IE and test 3 does the same for Apprunner,
so those tests aren't currently worth comparing.)

Also, if we wanted to be consistent with Nav4.x, we should default to a
monospace font on all INPUT fields.  I can't really say if we should do that or
not - personally I prefer a proportional font, though.

Comment 9

[Antti Näyhä]

Attachment: Test case using several font families for INPUT text fields

Comment 10

[Eric Pollmann]

After careful consideration, I've decided that I probably won't get this bug in
for M12.  Currently I have nearly 50 bugs scheduled for M13, so there is a
possibility that this bug may need to be moved out farther still.

Comment 11

[gerardok]

QA Contact update.

Comment 12

[Antti Näyhä]

Tests #2 and #3 in my 07/19/99 testcase are invalid - there was some seriously incorrect use of quotes in the style attributes.  My apologies for the
temporary lapse of reason.

Attaching a corrected test case.

Comment 13

[Antti Näyhä]

Attachment: Test case using several font families (FIXED VERSION)

Comment 14

[ekrock's old account (dead)]

Nonlethal cosmetic problem. Pushing out to M17.

Comment 15

[Antti Näyhä]

The sizes seem to be correct now, but each test in the test case uses a
monospace font instead of the suggested one.  This is due to 2357 - will verify
this one once that is fixed.

Comment 16

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 17

[Eric Pollmann]

2357 was fixed, so the right fonts are being used now.

This appears to be working now - more or less, but certainly better than it eer 
has in the past.  Marking WORKSFORME though it is really FIXED by Buster and 
other people who have worked on the GFX text widget.  Thanks!

Comment 18

[Antti Näyhä]

OK, here's another update (12/04/99 attachment test results on 3 browsers on
Win98 platform):

            Characters displayed on
Test no.  Mozilla  MSIE 5.0  Nav 4.72
-------------------------------------
1)        14,5     15        14
2)        27,5     17        30
3)        24,5*    15        22
4)        24,5     16,5      26
5)        14,5     14        14

(* = Mozilla is using Arial on this test, since it refuses to display MS Sans
     Serif.  Maybe this is because it's not a TrueType font?  I'll investigate
     and file another bug if needed.  Otherwise, fonts are fixed now - great!)

IMHO, we should definitely try to get closer to IE's results than rather than
Nav4's.  IE's algorithm is just a lot more realistic (except on test sections
1 and 5, which should show exactly 14 characters).

I'm reopening this, but lowering priority from Normal to Trivial.

Comment 19

[Eric Pollmann]

Rescheduling

Comment 20

[Eric Pollmann]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.

Comment 21

[Stanton McCandlish]

I'd like to register some disagreement with Antti's comments, but I've already put them 
in the related (duplicate?) bug 43422, so I won't re-paste them all here. (Short version: 
defaulting to non-monospaced font for a text entry field the width of which is specified in 
characters, completely breaks the functionality of SIZE on INPUTs of that type, e.g. 
TYPE="TEXT". If the author overrides the default with an explicit proportional font, then, 
of course, they get what they deserve. :)

I personally consider this problem to be non-trivial, since it's given me a load of layout 
headaches.

Comment 22

[Eric Pollmann]

This bug is also reported as bug 25657.  The most recent comments indicate this 
may also be fixed!  Please continue any discussions of this issue on that bug. 
Thanks!

*** This bug has been marked as a duplicate of 25657 ***

Comment 23

[cpratt]

I don't see how this is a duplicate of a bug filed over six months later, and 
that other bug was closed as INVALID (and to my eyes, this bug is definitely not 
invalid). However, if the engineer to whom this was assigned feels that way, 
well, who am I to argue? Marking verified.

Comment 24

[Eric Pollmann]

True, bug 25657 was technically a dup of this one, but 25657 was more recently 
investigated, so I think this way comments will end up in the right place.  I'll 
summarize the latest comments on that bug.