381631 - Cannot print pages in Landscape mode

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Adam Guthrie]

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.

Comment 1

[Adam Guthrie]

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.

Comment 2

[Eli Friedman]

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.

Comment 3

[Kenneth Herron]

Attachment: Patch v1

Swap width & height if landscape is set.

Comment 4

[Eli Friedman]

I'd say that it's a better idea to fix GetPageSizeInTwips; the other callers would also benefit from this change.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 266267 [details] [diff] [review]
Patch v1

what Eli said

Comment 6

[Kenneth Herron]

Attachment: Patch v2

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.

Comment 7

[Kenneth Herron]

Attachment: Patch v2 as checked in

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

Comment 8

[Kenneth Herron]

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.

Comment 9

[Eli Friedman]

You're passing a PRInt32* to a function that takes a double? I have no idea how that even compiles...

Comment 10

[Kenneth Herron]

(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.

Comment 11

[Eli Friedman]

(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

Comment 12

[Eli Friedman]

Oh, wait, I didn't spot the extra revision.  I'll take a closer look.

Comment 13

[Eli Friedman]

I have nothing to say; the reftests pass fine with the patch on my windows machine.

Comment 14

[Kenneth Herron]

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.

Comment 15

[Eli Friedman]

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.

Comment 16

[Eli Friedman]

Okay, here's another suggestion: try revving the UUID of nsIPrintSettingsService.

Comment 17

[Eli Friedman]

Oh, and also nsIContentViewer.

Comment 18

[Eli Friedman]

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?

Comment 19

[Akkana Peck]

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.

Comment 20

[Eli Friedman]

(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.

Comment 21

[Eli Friedman]

Checked in (with a clobber).

Comment 22

[Edward]

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.