Closed Bug 133984 Opened 23 years ago Closed 3 years ago

File inputs change size relative to other inputs if @media: print

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
trivial

Tracking

()

RESOLVED FIXED
Future
Tracking Status
firefox100 --- fixed

People

(Reporter: jsp, Assigned: dholbert)

References

()

Details

Attachments

(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020327
BuildID:    2002032708

While the file input and the submit button have the same height in the screen
rendering, the file input is taller in the print rendering.  Ideally, for any
given media, both controls would have the same height. Furthermore, if their
relative heights change based on media, it violates the rule of least astonishment.

Reproducible: Always
Steps to Reproduce:
1. Load the page at the URL.
2. Compare the sizes of the file input Browse... button and the submit button.
3. Print the page or look at it in print preview.
4. Compare the size of the buttons again.

Actual Results:  Both buttons are the same size when displayed on screen. The
file input's Browse... button is taller than the submit button when printed.

Expected Results:  Both buttons should have the same height when printed.

Bug 112156 was fixed by adding 
  input[type="file"] { height: 2em; }
to forms.css. (I believe the change was for print media only.) I'd think that
reducing the height to match the height of submit buttons would do the trick.
No duplicates found. Confirming on Build ID: 2002040203 (0.9.9+) Windows 98.

Looks to be about a pixel larger. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
On my machine, the total height of the browse button is 27px, vs 23px for the
submit button, a ratio of about 1.17. If I text zoom to 200%, the sizes are 53px
and 38px, a ratio of about 1.39. Since the ratios differ significantly, I'm not
sure this can be addressed by changing the height of [input type="file"] as I
earlier suggested, though it's worth a try.

For what it's worth, the font size is the same in each case; the difference
appears to be in the bottom padding.
the 2em was put in there because it was sizing to the entire page or lrager, so
there is a different problem that needs to be fixed. but I don't think we are
going to have before 1.0
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Future
Assignee: rods → nobody
Status: ASSIGNED → NEW
QA Contact: sujay → printing

Clearly not P1 priority at this point.

Having said that, this is still sort-of reproducible in a modified version of the testcase. The print-specific input[type="file"] { height: 2em; } CSS rule (mentioned in comment 0) is still present in forms.css:

@media print {
 [...]
  input[type=file] {
    height: 2em;
  }
}

https://searchfox.org/mozilla-central/rev/efc480f2188fb43c9cccdfd2eef79749a19c20a3/layout/style/res/forms.css#742

This doesn't have an obvious impact on the widget's rendering, since nowadays <input type="file"> doesn't get visibly taller when you specify an increased height on it; but it does occupy a larger amount of space on the page, as can be seen by e.g. adding a custom outline around it.

Priority: P1 → --

As noted in comment 0, this hardcoded height was to fix bug 112156, which was about file input widgets growing to fill the whole page (!) when printed.

That does not happen anymore, if I remove that CSS rule. So I don't think we need that CSS rule anymore.

--> taking, let's see if we can just fix this and get rid of this rule.

Assignee: nobody → dholbert
Component: Printing: Output → Layout: Form Controls
OS: Windows 2000 → All
Hardware: x86 → All
Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/930c93ea3cba
Remove no-longer-needed print-specific 'height' for file input widgets. r=emilio
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/33257 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: