Closed Bug 1280159 Opened 5 years ago Closed 5 years ago
Page Setup Margin Widths use Millimeters Instead of Inches (for paper Legal US e
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160604131506 Steps to reproduce: Select File, Page Setup..., Margins & Header/Footer. Actual results: The margins are in millimeters. Prior to version 46, the margins were in inches. Expected results: The margins should be in inches as I'm still using Letter size (8.5" x 11") paper and not a metric size. Using about:config, I reset all prefs with "print, printer, margins, or paper" to default. The margins remain in millimeters (10mm) in the Page Setup... dialog box although in about:config they are shown in inches (0.393750011920929" which is a close approximation to 10mm). I have found no way to change back to inches. See https://support.mozilla.org/en-US/questions/1126411
Is it reproducible with a fresh profile? https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Component: Untriaged → Printing: Setup
Product: Firefox → Core
Nevermind, I'm able to reproduce it. Indeed, Print Setup displays margin sizes in mm instead of in when the paper size is Legal US e.g. (I tested on Win 7 with MS XPS Document Writer). Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=955993 ba4a2a6ed9c85b9fc6c3a4c0fe582b178f&tochange=fb4737474a9c50b44e0ec38e43d42ed8a119 b7ee
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(castingman) → needinfo?(bobowen.code)
OS: Unspecified → All
Hardware: Unspecified → All
Summary: Page Setup Margin Widths use Millimeters Instead of Inches → Page Setup Margin Widths use Millimeters Instead of Inches (for paper Legal US e.g.)
Version: 47 Branch → 46 Branch
I note that the title of this Bug report now refers to US Legal Size paper. The problem I've encountered is with my printer set to US Letter Size paper. Not sure if this is significant but thought I should mention it. Oh, and I did try a new profile and had the same problem.
Given that this is not a new regression in 47, we will have to live with it for another ~3 weeks. Hopefully we address this in 48 release.
I know what I need to do to sort this out, I'll get to it soon.
Assignee: nobody → bobowen.code
Regression from 46, tracking.
Also, changed the other paper size conversion code to be similar, as I think it is easier to follow. Review commit: https://reviewboard.mozilla.org/r/61518/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/61518/
Attachment #8766708 - Flags: review?(jmathies)
Comment on attachment 8766708 [details] Bug 1280159: Let paper type drive page size units on Windows. https://reviewboard.mozilla.org/r/61518/#review58440 lgtm
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/a4999a2b771d Let paper type drive page size units on Windows. r=jimm
Hi Bob, do you want to uplift this for 48/49 if this patch is not too risky.
(In reply to Gerry Chang [:gchang] from comment #11) > Hi Bob, do you want to uplift this for 48/49 if this patch is not too risky. Yes, I'll just wait for it to hit Nightly and give it another test, then I'll request uplift, thanks.
Comment on attachment 8766708 [details] Bug 1280159: Let paper type drive page size units on Windows. Approval Request Comment [Feature/regressing bug #]: Bug 1238964 changed to just use millimetres on Windows. (Firefox 46) [User impact if declined]: Margin sizes unit will continue not to relate to the paper type. [Describe test coverage new/current, TreeHerder]: Manual testing, it would be good to get QA verification in Beta. [Risks and why]: Low(ish) - fairly simple change that maps paper type to size units and uses that for calculations. [String/UUID change made/needed]: None
Comment on attachment 8766708 [details] Bug 1280159: Let paper type drive page size units on Windows. This patch fixes a regression. Take it in 48 beta 6 and aurora.
This needs QE to test in beta.
According to Comment 13 (and also based on my investigations), this bug is only affecting Windows platform. I managed to reproduce this issue on 50.0a1 (2016-06-14). Also, I investigated it on - Windows 10 x64 - Windows 7 x64 The bug is verified fixed on - latest Nightly 50.0a1 (2016-07-10) - latest Aurora 49.0a2 (2016-07-11) - 48.0b6 build 1 (20160706215822) I will set the flags accordingly.
5 years ago
OS: All → Windows
You need to log in before you can comment on or make changes to this bug.