Subparts of file input don't size correctly.

RESOLVED WORKSFORME

Status

()

P2
normal
RESOLVED WORKSFORME
18 years ago
15 years ago

People

(Reporter: btiffany, Assigned: rods)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Here's an attempt to extract a simple (fixable?) bug from bugs like 52500 that
report strange styling with <input type=file>.  Namely, it seems that the height
of the text input is equal to the vertical distance from the very top of the top
border to the very bottom of the bottom border.  Likewise, the width of the text
input plus the width of the "Browse" button is equal to the horizontal distance
from the very left of the left border to the very right of the right border. 
The button looks reasonably sized, so I would guess that the bug is in the
sizing of the text input.  Consequently, file inputs can have their size set,
but any attempt to set a border or padding yields strange results (first three
test case items).  Properly sizing the text input to the content area of the
file input should solve this.

While the button is better, it has a problem when both the height and padding
are set on a file input, namely that it becomes too high in the same manner as
the text input (fourth item in testcase).  I presume this is because the button
is inheriting its height in forms.css and inputs use border-box sizing.  With
content-box sizing the problem goes away (see last item in testcase).

By the way, this is definitely NOT a dup of bug 65597 or of bug 52813.  Those
are about the file that a file input really has three parts,

input[type=file],
input[type=file] > input[type=button], and
input[type=file] > input[type=text]

and that authors are setting styles on the first and expecting them to apply to
the third.

it is related to bug 52500, save that said bug has accumulated, via comments or
dups, at least a few unrelated issues and never really articulates the present
issue (though its fairly clear from Ian's testcase).
(Reporter)

Comment 1

18 years ago
Created attachment 41602 [details]
Test page illustrating sizing issues.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

17 years ago
*** Bug 102095 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
(Assignee)

Updated

17 years ago
Priority: -- → P2
Target Milestone: mozilla1.2 → Future

Updated

17 years ago
QA Contact: madhur → tpreston
The way buttons lay out and form controls vertically align has changed a good
deal since this bug was filed.  What are the remaining problems here?  The
original description never clearly describes the problem that needs addressing...

No response, and the input is behaving the way I expect it to.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.