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
453 bytes, text/html
Details
testcase showing input and select/option problem
689 bytes, text/html
Details
Proposed patch
2.51 KB, 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 — 

    
    

    
  
-> 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
        — 
          — 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: