Closed Bug 103293 Opened 23 years ago Closed 21 years ago

[FIX]Input and option box sizes incorrect

Categories

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

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.6beta

People

(Reporter: boullet.marc, Assigned: bzbarsky)

References

Details

(Keywords: testcase)

Attachments

(3 files)

testcase
(deleted), text/html
Details
testcase showing input and select/option problem
(deleted), text/html
Details
Proposed patch
(deleted), patch
rbs
: review+
rbs
: superreview+
Details | Diff | Splinter Review
Consider the following: <html> <head> <style type="text/css"> .FONT2 {font-size:10pt; font-family: Courier New, monospace;} </style> </head> <body> <form name="form1"><input type="text" class="FONT2" name="tp1" size="4" value="12345"></form> <form name="form2"><input type="text" class="FONT2" name="tp2" size="4" value="1234" onfocus="this.blur()"></form> </body> </html> 1. the text boxes are displayed with 5 character positions though they have a size=4 parameter. Works normally with 4.7, IE 2. the second text box still show the caret when selected despite this.blur(). Should be a dup, but I can't find it. Build ID 2001100403 NT4SP6a 1 was working as expected (at least as I expect) with previous build (I'm quite sure it was working with 0.9.3) 2 never worked
Attached file testcase (deleted) —
-> rods (form controls issue)
Assignee: morse → rods
Component: Form Manager → HTML Form Controls
Keywords: testcase
QA Contact: tpreston → madhur
I see this, changing bug to new (w2k build 20011003)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'll have to take a look, it should be sizing better than that.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Summary: Size parameter in <INPUT TYPE="text"> not working properly → [TXT]Size parameter in <INPUT TYPE="text"> not working properly
Are any of these sufficiently simmilar to warrant consolidation via duplication or dependancy change? bug 33654 bug 52500 bug 92980 bug 103293 bug 109392 -matt
*** Bug 119057 has been marked as a duplicate of this bug. ***
I see the '<input TYPE="text" size=X>' off by one error on the Linux client too.
Attached is another testcase including input and select/option box examples. Input box is incorrect size whether or not 'type=text' is used. Also, option box is not correct size in a select element. All boxes in Netscape appears to be 1 character short. IE is rendering correctly. Website example: http://www.bloomberg.com -- In the top section there is an input box and a select/option box. Because the boxes are not wide enough, the table cell content is being pushed down which is causing the table cell at the right to have a gap at the bottom. Summary changed to include select option box problem.
Summary: [TXT]Size parameter in <INPUT TYPE="text"> not working properly → Input and option box sizes incorrect
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
*** Bug 117277 has been marked as a duplicate of this bug. ***
Priority: P1 → P2
I'm quite puzzled by pushing out this bug and dropping the priority to P2. Reading Mozilla press, I thought (naively) that the main goal of 1.0 was conformance to standards. "Size=x" is an early HTML feature that is working fine since NS 2.0. It's now nearly ONE YEAR that it is broken. Am I missing something ?
QA Contact: madhur → tpreston
input type=text sizing will be fixed with bug 92980 pretty soon. The problem is, there is no perfect algorithm for size=n with a variable width font. If you make it possible to accomodate "M"'s (the widest character, then the field is waaaay too big. But anything less could *potentially* make n characters not fit into the textbox. Bug 92980 switches us over to using something slightly bigger in most cases, but not so big as to accomodate n "M"'s. Option box size appears to be big enough now. Reopen if the problem still exists for those. *** This bug has been marked as a duplicate of 92980 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Depends on: 92980
Resolution: --- → DUPLICATE
The problem here is not with variable width font. As you can see in attachment #52213 [details], the text box asks (through css) for New Courier or monospace which are, AFAIK, fixed width fonts.
92980 should make us the same as IE for a fixed width font (will test on checkin).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Tested with 2002092404 which should have the patch for bug #92980. Results with testcase of attachment #52213 [details] are not OK. Though the text box seems a little bit smaller (the "5" does not appear entirely) than before, I think that, with fixed width font, we should have the exact width as you stated in bug #92980 comment #27: "we *always always* want to use (charwidth*size) where charwidth is the width of one character."
Reassigning to jkeiser
Assignee: rods → jkeiser
Status: REOPENED → NEW
Status: NEW → ASSIGNED
So right now the algorithm we use is: (ave char width) * (num chars) + (max char width) - 4px That last part is needed to get sizing right in the "variable width" case. Unfortunately, it's not clear to me how to make this happy in the fixed-width case... Perhaps that should be adjusted to: (ave char width) * (num chars - 1) + (max char width)? Assuming (max char width) - (ave char width) is about 4px for typical fonts, that should do what we want.... ccing some people who know far more about fonts than I; how realistic is that assumption?
er.. that assumption gives us nothing, since we just end up being smaller than the current size by (ave char width) - 4px with my proposed change.
Attached patch Proposed patch (deleted) — — Splinter Review
This just makes us not add the little extra bit for fonts where the ave and max char widths are equal (which are almost certainly fixed-width fonts).
Comment on attachment 135110 [details] [diff] [review] Proposed patch rbs, what do you think?
Attachment #135110 - Flags: superreview?(rbs)
Attachment #135110 - Flags: review?(rbs)
Taking.
Assignee: john → bz-vacation
Status: ASSIGNED → NEW
OS: Windows NT → All
Hardware: PC → All
Summary: Input and option box sizes incorrect → [FIX]Input and option box sizes incorrect
Target Milestone: Future → mozilla1.6beta
Comment on attachment 135110 [details] [diff] [review] Proposed patch r+sr=rbs
Attachment #135110 - Flags: superreview?(rbs)
Attachment #135110 - Flags: superreview+
Attachment #135110 - Flags: review?(rbs)
Attachment #135110 - Flags: review+
Checked in.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
*** Bug 141526 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: