Closed Bug 186325 Opened 22 years ago Closed 22 years ago

Breadth differs by <INPUT TYPE="text" SIZE="x"> and <INPUT SIZE="x" TYPE="text">.

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: nivoside, Assigned: peterv)

Details

Attachments

(2 files)

The sample of HTML.
118 bytes, text/html
Details
testcase
1.36 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.3a) Gecko/20021220 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20021220

A size element will be disregarded when referred to as <INPUT SIZE="x" TYPE="text">.
It seems that width is always interpreted as 20.

Being ignored if the turn of an element becomes reverse is troubled.
It should be interpreted exactly.

A problem occurs after 2002-12-17-08-trunk.
2002-12-17-04-trunk has no problem.

Reproducible: Always

Steps to Reproduce:
A page with the following HTML is opened:

<HTML><BODY>
<FORM><INPUT TYPE="text" SIZE="32"></FORM>
<FORM><INPUT SIZE="32" TYPE="text"></FORM>
</BODY></HTML>
Actual Results:  
The width of two input field differs.

Expected Results:  
The width of the two input fields is the same.
Attached file The sample of HTML. — 

    
    

    
  
WFM 2002121008/NT4

Maybe need to clean xul.mfl / compreg.dat stuff?


    
    

    
  

      
      
      
      

        Attached file
          
        testcase
        — 
      

    


  
Well, I'm seeing this problem on Win98 and MacOS9.
Attaching Testcase.

    
    

    
  
Is this only a problem with the themed controls on Windows?

    
    

    
  
> A problem occurs after 2002-12-17-08-trunk.
> 2002-12-17-04-trunk has no problem.

peterv, this is when your DOM2 HTML stuff landed...  Could the changes to 
GetSize/SetSize be the problem here?


    
    

    
  
Ah, hmm. That could be, yes. The problem is that the unit for the size is
dependent on the type of the input. My code looks at the type when the size
attribute's value gets set, but we probably don't know the type (yet).
I'm away on holiday for two weeks, I'll try to look at it but if anyone wants to
take this, please do. 

    
    

    
  
well, confirming and to peter for now...
Assignee: form → peterv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.3b?
OS: Windows XP → All
Hardware: PC → All

    
    

    
  
*** Bug 187494 has been marked as a duplicate of this bug. ***

    
    

    
  
Although the problem had occurred also by Phoenix before, it is repaired
temporarily?

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.3a) Gecko/20030115 Phoenix/0.5

    
    

    
  
When viewing the testcase in attachment 109864 [details], I see the differences of sizes
under Gecko/20030112 Phoenix/0.5, XP Pro SP1.
The testcase in attachment 109864 [details] WFM under Mozilla 1.3b 2003011713, XP Pro SP1.

    
    

    
  
This looks fixed to me, probably by the fix for bug 188872.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
  
Flags: blocking1.3b?

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: