Closed Bug 1457628 Opened 6 years ago Closed 5 years ago

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

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox64 --- wontfix
firefox70 --- fixed

People

(Reporter: jeffersoncarpenter2, Assigned: emilio)

References

Details

Attachments

(2 files)

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.
See Also: → 1458644
(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)
See Also: → 1460186
Flags: needinfo?(ntim.bugs)
Attached file Test case
Attachment #9006143 - Attachment mime type: text/plain → text/html
Still an issue after fixing bug 1495153.
Version: 59 Branch → unspecified
Assignee: nobody → emilio

Inheriting block-size is just plain wrong in presence of calc or percentages.

The layout without these rules also matches other browsers, so I see no reason
not to do this.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/13b62d64e105
Remove broken rule for the file input button. r=jfkthame
Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ff1a058434a3
Remove broken rule for the file input button. r=jfkthame
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
QA Whiteboard: [qa-70b-p2]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: