File inputs change size relative to other inputs if @media: print
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
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.
Comment 1•23 years ago
|
||
No duplicates found. Confirming on Build ID: 2002040203 (0.9.9+) Windows 98. Looks to be about a pixel larger.
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.
Comment 3•23 years ago
|
||
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
Updated•15 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
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;
}
}
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.
Assignee | ||
Comment 5•3 years ago
|
||
Assignee | ||
Comment 6•3 years ago
|
||
Assignee | ||
Comment 7•3 years ago
|
||
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.
Assignee | ||
Comment 8•3 years ago
|
||
--> taking, let's see if we can just fix this and get rid of this rule.
Assignee | ||
Comment 9•3 years ago
|
||
Comment 10•3 years ago
|
||
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
Comment 11•3 years ago
|
||
bugherder |
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
Description
•