Closed Bug 381631 Opened 14 years ago Closed 14 years ago
Cannot print pages in Landscape mode
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070522 Minefield/3.0a5pre Steps to reproduce: 1. Go to http://www.mozilla.org/ 2. File > Page Setup > Select Orientation: Landscape 3. File > Print (or Print Preview) Actual results: Page is printed in Portrait mode. Expected results: Page is printed in Landscape mode. Not sure how long this has been broken, but it works OK on branch.
Regressed between 2007-02-13-04 and 2007-02-14-04: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-13+03&maxdate=2007-02-14+05&cvsroot=%2Fcvsroot Looks like fallout from bug 369834.
Bleh, Linux seems to have a lot of problems with the printing code... works just fine on Windows. I'd appreciate someone with a Linux box debugging this.
Flags: blocking1.9? → blocking1.9+
Swap width & height if landscape is set.
I'd say that it's a better idea to fix GetPageSizeInTwips; the other callers would also benefit from this change.
Comment on attachment 266267 [details] [diff] [review] Patch v1 what Eli said
Attachment #266267 - Flags: superreview?(roc) → superreview-
The device context spec versions of GetPageSizeInTwips were all just wrappers around the nsIPrintSettings version, and there were no callers aside from the code at issue here. So I just removed the device context spec functions. I renamed the nsIPrintSettings function to GetEffectivePageSize to clarify that it's not returning the same thing as the pageWidth and pageHeight attributes. There's one GetPageSizeInTwips call in the old postscript generator code that I haven't bothered to fix.
Attachment #266404 - Flags: superreview?(roc) → superreview+
I checked in patch v2, but it apparently caused the printing reftests to fail on qm-winxp01 and qm-win2k3-01: REFTEST UNEXPECTED FAIL (LOADING): file:///C:/slave/trunk_2k3/mozilla/layout/reftests/printing/blank.html REFTEST UNEXPECTED FAIL (LOADING): file:///C:/slave/trunk_2k3/mozilla/layout/reftests/printing/272830-1.html
Backing out the patch fixed the test failures. I don't have a windows system to test on, and the reftest wasn't failing on linux or mac, so I'm not sure I can troubleshoot this.
You're passing a PRInt32* to a function that takes a double? I have no idea how that even compiles...
(In reply to comment #9) > You're passing a PRInt32* to a function that takes a double? I have no idea how > that even compiles... There was a problem with patch v2 that I corrected. If you see a problem with "patch v2 as checked in", I'd like to know what it is.
(In reply to comment #10) > There was a problem with patch v2 that I corrected. If you see a problem with > "patch v2 as checked in", I'd like to know what it is. What you checked in: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/widget/src/windows&command=DIFF_FRAMESET&file=nsDeviceContextSpecWin.cpp&rev1=3.62&rev2=3.63&root=/cvsroot
Oh, wait, I didn't spot the extra revision. I'll take a closer look.
I have nothing to say; the reftests pass fine with the patch on my windows machine.
The patch should be a big no-op unless landscape orientation is set. The reftest code doesn't set an orientation, but it's possible that the profile being used for the tests is set to print in landscape. "UNEXPECTED FAIL (LOADING)" means the test timed out while loading. The timeout is 10,000 ms.
Here's a suggestion: land the patch again, and request a clobber on the windows boxes running reftests. I recall running into an odd issue with reftests that went away as soon as I clobbered.
Okay, here's another suggestion: try revving the UUID of nsIPrintSettingsService.
Oh, and also nsIContentViewer.
Actually, the suggestion was made that you didn't cause a clobber properly. Maybe try getting someone else to do it sometime during the week?
Any chance of a fix on the 1.8 branch, since this is a regression? I tried applying the patch but the code is massively different so it requires a lot of hand patching, which I may flub not being familiar with the code.
(In reply to comment #19) > Any chance of a fix on the 1.8 branch, since this is a regression? I tried > applying the patch but the code is massively different so it requires a lot of > hand patching, which I may flub not being familiar with the code. It's not broken on the 1.8 branch! Any problem you're running into is not this bug.
Checked in (with a clobber).
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
A aimilar problem may exist in SeaMonkey 2.0. for Linux. Build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/200707260303 SeaMonkey/2.0a1pre See Bug 389949.
You need to log in before you can comment on or make changes to this bug.