Closed Bug 25657 Opened 25 years ago Closed 23 years ago

[FIX]When does 18 = 29? When you use the SIZE attritbute in a text type input field.

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
All
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: edmanet, Assigned: rods)

References

(
URL
)

Details

Attachments

(3 files, 5 obsolete files)

Testcase that is actually relevant
587 bytes, text/html
Details
screenshot of testcase -- WinXP IE6 and Mozilla 3-4-2002 build
27.08 KB, image/png
Details
testcase -- size=50
710 bytes, text/html
Details
This drives me nuts. I use this code: <input type='text' name='whatever' size='18'> When I load it up in Netscape 4.x, I can get an input field that is 29 characters wide. What's up with this? This is one of the only reasons that I can't make truly browser independent web sites. Of course the work around is to determine the browser and adjust the control size (cut them in half). Why do you wanna make extra work for me? Please... please...
Reassinging to Rod.
Assignee: karnaze → rods
Attached file simple test (obsolete) —
Attached is a simple example of where ths size is set to 18. This example shows 18 chars in Nav 4.x, 18.5 char in Mozilla (in NavQuirks mode) but the form control is 153x24 pixels for Nav 4.x and Mozilla. In IE 4.0 it shows 19 chars and is 139x22 pixels. If you are setting a different font for the text field, the sizing does get off because of the simplistic algorithm that was used plus a rounding error in the font size calculation. We have corrected the rounding error for the font size calc, so Mozilla in NavQuirks mode will not always match 4.x. Mozilla in standard mode should always size to the correct amount of chars. Once IE completely implements CSS maybe their text controls will always size to the "size" attribute. I am marking this bug as invalid because there really isn't a problem to be corrected here, because Mozilla in "Standard" mode will size to the correct number of chars (if not, then that is a bug) If you a very specific issue that doesn't appear to be covered by this example please enter it and some sample HTML.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Marking VERIFIED INVALID on: - Linux6 2000-03-01-13 Commercial build - MacOS9 2000-03-01-13 Commercial build - Win98 2000-03-01-16 Commercial build
Status: RESOLVED → VERIFIED
*** Bug 43422 has been marked as a duplicate of this bug. ***
*** Bug 7543 has been marked as a duplicate of this bug. ***
From bug 7543: - Stanton McCandlish asks essentially "please default to monospace". Though not stated, I'm guessing this means in quirks mode. I just tested this and we are displaying monospace by default <invalid> - Antti Näyhä included a table of the number of characters actually displayed versus the number requested for SIZE=14, various fonts, standards mode. The attachment uses arbitrary characters (specifically 0-9) to determine how many will fit if width is set to 14. The benchmark character is %. I just tested in today's build. All five examples fit between 13.5 and 14.5 % characters, which I think is very close to what is requested.
*** Bug 44786 has been marked as a duplicate of this bug. ***
*** Bug 53054 has been marked as a duplicate of this bug. ***
Attached file test with 3 INPUT elements (obsolete) —
I don't think this bug is invalid - I don't really know what is NavQuirks and Standart mode, but in Netscape 4 the attachment 14986 [details] the INPUTs have always 6 chars length, but in Mozilla only the second one matches, the others are absolutely stupid.
NavQuirks mode is non-strict documents, Standard mode is strict documents. In navQuirks we try very hard to behave like nav 4.x even if it breaks the standard (HTML 4.0 Standard) For the first two text fields we size pixel for pixel on the outer edge. As far as these two displaying more of the text string it is the difference in the way native controls are displayed versus the way we display them. Native control use a three pixel border, but it visually looks like two, then they use a one pixel padding, and then they do not display any of the next char even thought some of it would fit. In NavQuirks mode we use a two pixel border and no padding. I could change the control to use a two pixel padding, but some of the next char would be painted. Adjustments could be made with padding, but apparently that doesn't work so I will have to file a bug.
*** Bug 53054 has been marked as a duplicate of this bug. ***
*** Bug 58338 has been marked as a duplicate of this bug. ***
Please see attach 19864 - this bug is NOT invalid, I think.
Don't compare it to IE, compare it to Nav 4.x and you will see that they measure the same width and height in pixels. Our goal was to match Nav 4.x, not IE.
Hey, this is untrue ! I opened the attach 14986 with NN4 (linux) and all INPUTs have the size 6. With IE, they have the size 6 or 6.5 (see attach 19864), but mozilla has 10 !!! I believe the main goal with mozilla was to be standard-compliant, the HTML 4.0 specs says: size = cdata This attribute tells the user agent the initial width of the control. The width is given in pixels, except for control types "text" and "password" when it is the (integer) number of characters. IS really 6 equal to 10 and 18 equal to 29 ?
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Let me be a little more clear, the intention was for them to size exactly the same on Netscape 4.x for Windows. Most all the content in the world is developed for IE on Windows and Nav 4.x on Windows. Many sites construct their HTML just so, so the pages lay out perfectly on Windows, then it lays out however on Linux and Mac. The requirements I obey are as follows: 1) When a page is not in "strict" mode it must size on the Windows platform the same as Nav 4.x on Windows (it does that) 2) When in Standard or Strict mode and the "size" is set, it must size correctly when in a fixed width font (this is not working correctly, there is an extra char being added in) 3) When in Standard mode and the font is a variable width font it is completely unclear as to what algorithm should be used to calculate it's size. I will leave this open to fix the fixed width font problem in Standard mode, which is the only bug I can find.
Status: REOPENED → ASSIGNED
here is the fix for the monospace off by 1 sizing issue: Index: nsGfxTextControlFrame2.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp,v retrieving revision 1.108 diff -u -r1.108 nsGfxTextControlFrame2.cpp --- nsGfxTextControlFrame2.cpp 2000/11/17 00:25:30 1.108 +++ nsGfxTextControlFrame2.cpp 2000/11/30 21:23:09 @@ -1387,9 +1387,9 @@ if (NS_CONTENT_ATTR_HAS_VALUE == colStatus) { // col attr will provide width PRInt32 col = ((colAttr.GetUnit() == eHTMLUnit_Pixel) ? colAttr.GetPixelVal ue() : colAttr.GetIntValue()); col = (col <= 0) ? 1 : col; // XXX why a default of 1 char, why hide it - aDesiredSize.width = (col+1) * charWidth; + aDesiredSize.width = col * charWidth; } else { - aDesiredSize.width = (aSpec.mColDefaultSize+1) * charWidth; + aDesiredSize.width = aSpec.mColDefaultSize * charWidth; } aRowHeight = aDesiredSize.height;
Summary: When does 18 = 29? When you use the SIZE attritbute in a text type input field. → [FIX]When does 18 = 29? When you use the SIZE attritbute in a text type input field.
rods patch looks good. r=kmcclusk@netscape.com
sr=waterson
fixed the one char too big problem when in standard mode.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
->gerardok
QA Contact: ckritzer → gerardok
I really think this bug should be reopened. Your solution to violate standarts just because of already-dead Netscape 4.0 on Windows seems completely mad to me. Why don't mozilla team implement document.all then ? So many websites are using document.all, it would be very helpful (I don't know _any_ site optimized for "Netscape 4.0 Windows edition"). Correctly written web page is rendered wrong with NN 4.0 - ok, it's a bug. But it should be fixed, not supported !
verified on build 2001-08-14-trunk
Status: RESOLVED → VERIFIED
I agree with the above criticism. The Windows platform snobbery is not even apropos for quirks mode, when the "quirk" in question is clearly a bug, not a feature of any kind. It's even one that's been avoided and fixed in every other browser/OS combo I'm aware of. IT BREAKS THE HTML SPEC'S FUNCTIONALITY. This bug desperately needs to be reopened and *really* fixed. "This is one of the only reasons that I can't make truly browser independent web sites." That's not going to change until this bug is reopened and corrected (and the correction propagates to the next Netscape release, to boot.) From my related, duplicate-marked, bug: ***** One of the commentators in Bug 7543 says essentially that this is a feature, not a bug, but I beg to differ. Said respondent .[rods; I didn't have the bug in qusetion in front of me at the time - 20020306] suggests basically that the browser should just be allowed to guess, since it uses a proportional (non-monospaced) font for text entry. This strikes me as completely absurd. Using such a font is obviously a bug in and of itself (one inherited unfortunately from most Windows browsers; I don't know of any other browsers that have this problem), because unless a monospaced (non-proportional) font is used, the SIZE attribute of INPUT TYPE="TEXT" is rendered completely and totally useless. Secondary effects include mangling of carefully arranged layout (a problem that's been vexing me enough to report it.) I do not know if Mozilla for Windows or *n*x suffers from this problem. I note that Netscape 4.x for Mac does NOT have this problem, and neither does IE 4.x or 5.x for Mac. Both IE 4.x and NS 4.x for Windows have this or a similar problem (NS 4.x/Win has the same problem, IE 4.x/Win. DOES use a monospaced font, but mis-sizes the field by about 3 or so characters anyway, at least on this test page.) At any rate, text entry in any field the size of which is set in characters MUST necessarily be in a monospaced font, or it breaks the functionality of this aspect of HTML. ***** If rods is unwilling to fix it, is anyone else? Look at the comments here, and look at the number of duplicates. This is obviously something that is bothering a lot of people. So, if you care about this bug, vote for it, and if you're in a position to re-open it, please do so. I appreciate that rods fixed the off-by-1 error, but that's actually a different bug than the one at issue here. PS: As noted elsewhere, I agree that IF an author does something to override what is (or in Moz.'s case *should be*) the default behavior of making INPUT text be monospaced (e.g. by assigning it a proportional font with styles), then but ONLY then is Moz.'s current behavior sane (and it really is then - Mozilla wouldn't have much choice.) PPS: I'm Cc'in seemingly interested parties from this and duplicate bugs, to hopefully get some broader concensus on this. Right now it looks like a single individual has effectively vetoed this bug getting ever fixed, over numerous objections.
Reopening. We use "font: field;" for <input type="text"> and "font: medium -moz-fixed;" for <textarea>. It seems to me we should be using the same font for both, and Stanton McCandlish has given very good reasons why the default font for <input> should be "-moz-fixed" rather than "field". The reason we don't use "field" for <textarea>, of course, is that "it screws up too many pages". The testcase in this bug is no longer applicable because it happens to use characters which fit exactly in the width. Using capital "W" characters instead of digits would demonstrate the problem immediately in the middle textfield in the testcase.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached file testcase (obsolete) —
This is a testcase that has 3 size 5 text inputs with different font families set (monospace, sans-serif, and serif).
This testcase tests the remaining problem -- a variable-width font being used for <input> elements for which no font is specified. If a font _is_ specified then what we do is correct. It is only when no font is specified that we get odd behavior.
Attachment #4700 - Attachment is obsolete: true
Attachment #14986 - Attachment is obsolete: true
Attachment #19864 - Attachment is obsolete: true
Attachment #19954 - Attachment is obsolete: true
Attachment #72970 - Attachment is obsolete: true
This is a screenshot of the just posted testcase. This series of bugs has always been about nav4's rendering of text inputs where it "doubles" the size of the box. Honestly, I do not see this anymore. Look at the screenshot. Since Rod hooked up the strict sizing model (a year ago?) and ditched the quirk width rendering in mozilla, I think that mozilla renders this better than even IE6. I'll post another testcase bumping the size to 50 and again you'll see that mozilla renders this just like IE6 or better. I'm missing what the problem is now? Boris using "-moz-fixed" rather than "field" should be another bug report since it is a different can-of-worms right?
Attached file testcase -- size=50 —
The same testcase except that it now has size=50 instead of size=5. To my eyes (without going to the pixel level) current mozilla build renders just like IE6 in XP.
James, it is _not_ a separate can of worms. Read the opening comment on this bug again. Then read the dups carefully. Both this bug and half the dups are about the problem I'm talking about, which has nothing to do with what you're talking about or what got "fixed" in this bug.
What exactly is the problem for why this bug was re-opened? When comparing Moz to IE 6.0 the fonts for input type=text and textarea look exactly the same. And we just aren't gooing to support NavQuirks anymore for these. I am sure the user base of Nav 4.x is small and few sites are probably developing for it, so I would rather have this discussion not focused on quirks. So I did some sizing tests and we do size a little smaller than IE for inputs and slightly bigger for textareas. The bottom line is "size=xxx" is meaningless when you use a proportial font like IE and Moz does for inputs. If the bug is open because you want us to get closer to how IE sizes, then that is reasonable.
> The bottom line is "size=xxx" is meaningless when you use a proportial font like > IE and Moz does for inputs. Right, so why are we using a proportional font for inputs by default? We don't do it for textareas...
Boris wouldn't this be better discussed with bug 53617 (comments 40 - 42 -- remember my email last week) or even better bug 106317 since that bug has turned into a kind of general polish up of form controls (render consistent). For example, you point to the fact that mozilla uses a fixed font for textareas while everything else is proportional. Seems reasonable that textareas should use the same font as the other controls. Let's leave this bug just for size/width of text boxes.
OK. reading over all the relevant bugs I see that people can't make up their mind as to what the hell they want in any of them. Reclosing this one; filed specific bugs on specific issues: Bug 130632 filed on the fact that on Mac the "field" font is unconditionally mapped to "sans-serif". Bug 130635 filed on the fact that on Linux the "field" font seems to sometimes get mapped to "sans-serif". Bug 130637 filed on the fact that none of the nice code from bug 53617, comment 53 is ever executed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
and verified, as it was (to be clear, verified that we now size pretty much like IE in the case of variable-width fonts).
Status: RESOLVED → VERIFIED
James Lariviere wrote: > mozilla uses a fixed font for > textareas while everything else is proportional. Seems reasonable that > textareas should use the same font as the other controls. And, just to be clear, this should surely default to monospaced, so that the WIDTH attribute of TEXT TYPE="INPUT" actually has any useful function in HTML at all, and only become proportional/variable width IF the page author manually codes it that way. Right?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: