290327 - CSS width applied incorrectly for the form input fields of type="file"

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Pawel Widera]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 Mnenhy/0.7.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 Mnenhy/0.7.1

For a given tag:
<input type="file" size="12" style="width:15em">
a gap space, of width equal to the value of the CSS width property minus the
value of the HTML size attribute, is shown next to the browse button.

Reproducible: Always

Steps to Reproduce:
1. Use two different values for the file input HTML size attribute and the CSS
width property.
Actual Results:  
A white gap next to the browse button is shown.

Expected Results:  
The size of an input file form field should be equal to the value of the CSS
width property (the value of the HTML size attribute should be ignored), and no
gap should be present. An input file element width should be the same as the
width of an input text element (see the testcase in IE).

This is not a duplicate of the bug 52500. This is just a subset of it, which
hopefully could be quickly fixed, whereas bug 52500 is also about formatting the
text input and a button together (border, background, font) and probably would
never be fixed due to the lack of CSS specification wording in this matter (see
Boris Zbarsky comments: bug 52500, comment 27 and bug 52500, comment 30).

This bug is filled in the spirit of bug 52500, comment 67 and bug 52500, comment
88 to achieve some fixes as soon as possible, without another five years of
discussion.

Comment 1

[Pawel Widera]

Attachment: testcase

Comment 2

[Pawel Widera]

Attachment: testcase IE screenshot

Comment 3

[Gérard Talbot]

This looks like bug 52500.

*** This bug has been marked as a duplicate of 52500 ***

Comment 4

[Gérard Talbot]

Oops... sorry

Comment 5

[Ruvim Pinka]

Attachment: one more test case

Firefox 3.0 beta 5, the bug still exist.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I'll take a shot at this if someone can spec out the behavior we want here.  One suggestion in bug 52500 was that the text input should change size to fit the overall width of the file input as specified in CSS.  Things that need to be specified assuming we want to do that:

1)  How does the size="" attribute interact with the width style?
2)  What happens if the width style is smaller than the width of the button?

Comment 7

[Rodrigo Ruiz]

I think it should be something like:

- The CSS width property must be applied to the whole input component (text + button)
- The CSS property must take precedence over the HTML size attribute. That is, if both are defined, size must be ignored.
- The width of the button should work like an implicit CSS min-width attribute, so the actual component width should be Max(CSS width, button width)

Hope this helps,
Rodrigo Ruiz

Comment 8

[Boris Zbarsky [:bzbarsky]]

> The width of the button should work like an implicit CSS min-width attribute

That would be a pretty serious violation of the CSS spec, actually.  I'm not sure we want to do that.

Comment 9

[Rodrigo Ruiz]

No problem, my intention was to have a draft to work on :-)

Another option would be to "hide" the text field (or just leave it with width:0px), and mimic the behaviour for simple buttons.

This way, the width calculations would be something like:

buttonWidth : min(width, defaultButtonWidth)
textWidth   : max(0, width - buttonWidth)

Regards,
Rodrigo

PS: I have never seen the source code of Gecko, so I don't even know if this comment is useful at all :-D

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, it's useful.  So if I understand the proposal correctly:

1)  size attribute on textfield should only be used if the file input is
    auto-width.
2)  When file input is not auto-width, then:
    a)  button width is intrinsic width
    b)  text input width is max(0, width - buttonWidth)
    c)  If the total input width is too small for the button, it overflows (which
        is what happens right now anyway if the total width is too small).

Sound about right?

Comment 11

[philippe (part-time)]

(In reply to comment #10)

> Sound about right?

Yes, that is what Opera and WebKit do: the textfield is sized to fill the available width, CSS width overrides the size="" attribute.

In the case of width < buttonWidth, both Opera and WebKit clip the button (overflow:hidden). That doesn't sound right.

Comment 12

[Rodrigo Ruiz]

(In reply to comment #10)

> Sound about right?

Yes, it looks right for me too :-)


(In reply to comment #11)

I think in this case this is a minor issue. Both clip and overflow make sense, and it will make a difference in only a very few cases. The usual case, at least from my experience, is that these fields are far wider than their button width.

Said this, I would prefer to have consistent behaviour with other render engines:

 * It makes my web developing days easier ;-)
 * And any later change would modify the rendering of existing pages :-S

So, I would say I prefer to clip rather than overflow.

Comment 13

[Brad Koch]

Attachment: Demonstration of standard overflow behavior

Comment 14

[Brad Koch]

> I think in this case this is a minor issue. Both clip and overflow make sense,
> and it will make a difference in only a very few cases. The usual case, at
> least from my experience, is that these fields are far wider than their button
> width.

They both may make sense, but only one is correct default behavior.  The CSS 2.1 Candidate Recommendation says that the default value for overflow is visible.  The expected results are demonstrated in the above attachment (https://bugzilla.mozilla.org/attachment.cgi?id=336844).

It is also worth noting that clipping a file input would lead to the browse button being hidden.  Thanks to the fix for bug 258875, it would result in what appears to be magic text box that pops up the file upload box.  This isn't really a desirable behavior to allow, but the CSS standard still says overflow applies to "non-replaced block-level elements, table cells, and inline-block elements", which appears at first glance to include the <input type="file"/>.

So basically, the CSS standard says the overflow should be visible.  If someone wants to override it, they can set overflow:hidden, although this is not a desirable behavior.

Comment 15

[Rodrigo Ruiz]

Brad, you are totally right. With this, the proposal at comment #10 is the correct one :-)

Comment 16

[Boris Zbarsky [:bzbarsky]]

<input type="file"> is sorta a replaced element as far as Gecko is concerned, for what it's worth.

Comment 20

[Marius Hudea]

This input file is really screwed guys.. please fix it as soon as possible and leave major improvements for later versions.

I'm just trying to make the field a certain size and you'd think style="width:700px;" would work but it doesn't.
I have to use <input name="infile" type="file" style="width:722px;" size="104" /> to make it look almost the same in both Firefox and IE.

Also it's kind of ugly the way the Browse button is currently glued to the text field, it should have a couple of pixels of space between imho.

I've already reported in another bug the fact that the input file field is always white background which makes it hard to read when your site is designed to have yellow text on brown background for example.

As for later versions: maybe there could be an option implemented/mozilla specific css rule to show the browse button below the input field and aligned to the right of the input field. This way all text fields would have the same width on a form and would probably look better.

well... it's anyway better than Chrome's input field which doesn't follow any rule but please fix it guys..

Comment 21

[Robbie Paplin]

I should add, to make matters worse, size varies between platforms. For example, if you set size="75" on Firefox for Windows, you need to set the size to a different value on Firefox for Mac in order to look equivalent.

Comment 22

[Boris Zbarsky [:bzbarsky]]

size="NN" will size depending on the font for the control (just like text inputs), which varies by platform settings, user preferences, etc.

Comment 23

[Mike Lykov]

Hi, what about this bug?  :)

I have last beta for now - ff 10 beta6, and this bug are present.

See here for simple testcase:

http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_size_css

if I replace input type="text" to input type="file" and set style="width:150px" to 250px, 350px and so on, real field size (rendered on right side) are not change it's size.   

Is a css code in testcase wrong, or it is a bug with very long history and not resolved?

Comment 24

[Mounir Lamouri (:mounir)]

This should be fixed by bug 52500.

Comment 25

[j.j.]

Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20130521 Firefox/24.0
Attachment 180720 [details] is worse than before now, text unreadable on dark background

Comment 26

[j.j.]

> Attachment 180720 [details] text unreadable on dark background
filed bug 874600