Closed Bug 381631 Opened 14 years ago Closed 14 years ago

Cannot print pages in Landscape mode

Categories

(Core :: Printing: Output, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: ispiked, Assigned: kherron+mozilla)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

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.
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+
Attached patch Patch v1 (obsolete) — Splinter Review
Swap width & height if landscape is set.
Assignee: nobody → kherron+mozilla
Status: NEW → ASSIGNED
Attachment #266267 - Flags: superreview?(roc)
Attachment #266267 - Flags: review?(pavlov)
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-
Attached patch Patch v2Splinter Review
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 #266267 - Attachment is obsolete: true
Attachment #266267 - Flags: review?(pavlov)
Attachment #266404 - Flags: review?(pavlov)
Attachment #266404 - Flags: review?(pavlov) → review+
Attachment #266404 - Flags: superreview?(roc)
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.
Depends on: 388169
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.
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.