File input "Browse" button is vertically squished when given style "height: calc(.....)" due to block-size: inherit in forms.css

NEW
Unassigned

Status

()

defect
Last year
9 months ago

People

(Reporter: jeffersoncarpenter2, Unassigned)

Tracking

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 affected)

Details

Attachments

(1 attachment)

Reporter

Description

Last year
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

1. Optionally verify that the height of a file input by default is 23px.
2. Write this HTML code:

<div style="height:43px">
  <input style="height:calc(100% - 20px)" type="file" />
</div>

Which gives the input box a height of 23px, but does it by using a calc rule.


Actual results:

The web inspector shows that the input element has a height of 23px as before, but the "Browse" button is vertically squished.  The "Browse..." text is visible and in the right place, but only a sliver of the actual button appears.

Visually, it appears that given "height:calc(100% - Xpx)" on the input element, the button graphic is then given a height of "100% - (2*X)px".  In other words, the X has double the effect on the button as it does on the rest of the input element.


Expected results:

The button should have appeared at its normal size.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180502100112

I have managed to reproduce this issue on latest FF release (59), using Windows 8 and Windows 10.
I have used the https://codepen.io/pen/ website and the HTML code provided in the Description: 

<div style="height:43px">
  <input style="height:calc(100% - 20px)" type="file" />
</div>

I've also tested this on the latest Nightly build (61.0a1 (2018-05-02)) and the issue can be reproduced. 

Please notice that the issue does not occurs on other browsers.  

Based on the description and the tests executed, I will mark this bug as NEW.
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Product: Firefox → Core
Is this a regression?
Component: CSS Parsing and Computation → Layout: Form Controls
So, the reason this happens is that the button has block-size: inherit, which means that it inherits the calc(100% - 20px):

  https://searchfox.org/mozilla-central/rev/795575287259a370d00518098472eaa5b362bfa7/layout/style/res/forms.css#522

Here's a minimal repro without <input> magic:

<!doctype html>
<div style="height:43px">
  <div style="height: calc(100% - 20px)">
    <button style="block-size: inherit">Browse</button>
  </div>
</div>

This is expected, style-wise, since the computed value of height is calc(..). It'd also be a problem with percentage heights. This may need to use another kind of UA rule to make this work, or special-casing reflow maybe.

Looks like blink uses flex to handle file controls, perhaps we could do the same.
Looks like that height: inherit rule has been there since forever.
I guess this can be really a problem for all the "inherit"ed properties in ua.css / forms.css... Should we maybe audit them all?
Summary: File input "Browse" button is vertically squished when given style "height: calc(.....)" → File input "Browse" button is vertically squished when given style "height: calc(.....)" due to block-size: inherit in forms.css
Hmm.  So there used to be a point at which the computed value of height was an absolute value, I think, in the CSS2 (not CSS2.1) days.  At that point the "inherit" rule there made sense.

Yes, we should probably audit all the other "inherit" bits.

Using flex for the innards of a file control makes sense now that flexbox is supported.
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #6)
> Hmm.  So there used to be a point at which the computed value of height was
> an absolute value, I think, in the CSS2 (not CSS2.1) days.  At that point
> the "inherit" rule there made sense.
> 
> Yes, we should probably audit all the other "inherit" bits.

Filed bug 1458644 for that.

> Using flex for the innards of a file control makes sense now that flexbox is
> supported.

Maybe :bgrins, :ntim or other of the frontend folks could give this a shot? IIRC they've played with the file control stuff recently.

If not, let me know and I can maybe get to it when I'm back from PTO.
Flags: needinfo?(ntim.bugs)
Flags: needinfo?(bgrinstead)
I'm hoping to change the filepicker DOM/styles in Bug 1446830 to stop using XUL label. I just checked with that patch applied I don't see the squished Browse button with the markup from Comment 0.
Depends on: 1446830
Flags: needinfo?(bgrinstead)

Updated

Last year
Flags: needinfo?(ntim.bugs)

Comment 9

10 months ago
Posted file Test case

Updated

10 months ago
Attachment #9006143 - Attachment mime type: text/plain → text/html

Comment 10

9 months ago
Still an issue after fixing bug 1495153.
Version: 59 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.