Created attachment 522911 [details] desktop/laptop screen testcase At actual 96 desktop DPI, printing differs little among rv1.8.1, rv1.9.2 & rv2.0, as does screen display generally, except WRT form elements. When printed without author styling, form elements mushroom in size compared to their surroundings. With actual desktop DPI of e.g. 120 (125% or 96) or 144 (150% of 96), the size disparity grows in proportion to the DPI deviation from 96. To reproduce: 1-ensure desktop DPI set to 96 2-open rv1.9.x or higher with a virgin profile, or with default fonts reset to OEM values 3-print a page containing unstyled form elements 4-close browser 5-reset DTE to some higher DPI, e.g. 120 or 144 6-raise browser's default font sizes in same proportion as DPI was raised, e.g, from 16 to 20 for 120 DPI, or to 24 for 144 7-print a page containing unstyled form elements Actual results: 1-printouts at 96 DTE DPI seem reasonable except for large form elements 2-printouts above 96 DTE DPI seem reasonable except for even larger form elements 3-paper waste Expected results: 1-printouts at any DTE DPI have form elements printed in same proportion to text size as displayed on screen, similar to rv1.8.x
You're right. The dropdown menu, input field and buttons are not scaled along with the rest. I expect this is because they're supplied by the UI (in my case GTK+) and will always be rendered according to the system DPI (120 in my case). I patched my Firefox to scale stuff according to layout.css.dpi and it's clearly visible that this has no effect on those elements.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 4 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.