Closed Bug 118386 Opened 23 years ago Closed 21 years ago

"Browse..." button misaligned on <input type="file">


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

Windows 2000





(Reporter: don.burden, Assigned: rods)



(Keywords: testcase)


(4 files)

Using Mozilla 0.9.7.  In below sample HTML, the first "Browse..." button is
drawn too low, with a white area above button, and the height of the button
doesn't match the height of the input box.  After the second one is drawn
without a specified height, the third one is drawn with the same style as the
first but this time its drawn without the white area on top, but still doesn't
match the height of the input text box.

<HTML><BODY style="background-color:lightblue">

<input style="height:18px;width:300px" type="file">


<input style="width:300px" type="file"> 


<input style="height:18px;width:300px" type="file">

Not a DOM problem, reassigning.
Assignee: jst → rods
Component: DOM Level 0 → HTML Form Controls
QA Contact: desale → madhur
Looks like bug 52500....

<input type="file"> is _certainly_ not describable in terms of the CSS box 
model... We should probably just disallow setting height and width on it...
Commenting on what Boris Zbarsky said, the height MUST be specified in a 
type="file" input box.  If a font-size style is specified for all input 
elements, the height needs to be specified too for all input elements to make 
the box size look proportional to the text inside.  In IE, display is uniform 
between both file and text inputs.  With Mozilla/Netscape, for file types, the 
text box part looks ok but the "Browse..." button is badly out of whack.  One 
possibility is to make the height automatically change according to font-sise --
 this is what IE does.
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → Future
QA Contact: madhur → tpreston
Just tried Mozilla 1.0 RC1.  The "Browse..." button rendering has gotten even
worse.	HTML given when bug first submitted added as attachment.  Most
noticably, the background color above and to the right of the button is
rendered incorrectly.
please do not remove CSS styling of the input type='file' form element !

honestly, this would be a serious setback for mozilla. 

creating web apps (with well-designed interfaces), for which mozilla is
otherwise predestinied, would become much harder if not impossible in some cases
(check out my test case, what do i do?).

i don't see a way to workaround this bug by replacing the file field with a
combo of text+submit field and some javascript logic. if someone knows, please
post. but if someone gets up to do this, it would be better to fix the file form
element itself.

i honestly hope this will be resolved before 1.0.
with this bug, mozilla is like a brand new car shipped with a fender missing.

thanks for your great work.
Keywords: testcase
Most of the problems in the first attachment are fixed now that bug 167236 has
landed.  The "size-with-the-font" issue is fixed too -- see
in a build from Nov. 13, 2002 or later.

What remains to be done here?
Depends on: 167236
Ping?  What issues remain in this bug?
Pinging. Bug still exists in Mozilla 1.2.1.  Click on first attachment "HTML
illustrating...".  Background colors are whacked on the right side.  Button
drawn too low and button text not vertically centered on the first and third.
I checked in fixes for form control alignment _after_ the branch for 1.2 was 
cut.  Please test with 1.3a or newer builds.
This one looks like it could close...  Boris' test looks fine in Win32 build 
2003041009.  The attached testcase behaves exactly as IE does (just in case it 
didn't before ;).
Attached file Testcase #2
Boris, the remaining problem is that <input type=file> does not fill up its
assigned width.  You can see that it takes up room and paints its background
but that the text-field part of it is not sized correctly.
Also, the border-color is not picked up by the button.
This testcase works fine in IE.
Attached file Testcase #3
Testcase #3 (same as #2 but now with RTL direction)
Mats, that's bug 52500
Marking fixed, since original problem here was fixed in bug 167236
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.