324141 - Cannot change paper orientation in page setup dialogue

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Gulliver]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060118 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060118 SeaMonkey/1.5a

Cannot change paper orientation from upright to landscape or vice versa. I see this problem on 3 different machines. MacOS X 10.4.4.

Reproducible: Always

Steps to Reproduce:
1. Select page setup
2. Select page orientation "upright"
3. Select "Print"

Actual Results:  
Prints in landscape orientation, regardless of what was selected before.

Expected Results:  
Should print in upright orientation

Comment 1

[Stefan [:stefanh]]

I see this too with a recent seamonkey trunk cvs build (Mac OS 10.3.9) - at least in preview. No matter how many times I select the landscape orientation the page still displays upright in Print Preview. Seems to work on branch - at least with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060114 SeaMonkey/1.0b.

Note that I haven't actually printed any page (printer driver is lost atm).

Comment 2

[Samuel Sidler (old account; do not CC)]

Testing with the latest trunk nightly, I also see this using SM (01/22). However, this is not broken using the latest trunk nightly of Camino (01/22).

(Like Stefan, I only tested the preview, didn't actually print.)

Comment 3

[Gulliver]

Still broken in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060126 SeaMonkey/1.5a.

Why is this bug still considered "UNCONFIRMED"?

Comment 4

[Samuel Sidler (old account; do not CC)]

Does this happen in Fx trunk builds as well? Or is this a Sm-only regression?

(Oh, and confirming)

Comment 5

[Gulliver]

Works fine in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060127 Firefox/1.6a1. Seems to be a Seamonkey-only problem.

Comment 6

[Stefan [:stefanh]]

Gulliver, is there any chance that you can you find out when this regressed?

Comment 7

[Gulliver]

(In reply to comment #6)
> Gulliver, is there any chance that you can you find out when this regressed?
> 


Stefan,

it was still working o.k. in the built from December 26th and it was already broken on January 11th. Must have happend between these two dates. 

Comment 8

[Gulliver]

(In reply to comment #6)
> Gulliver, is there any chance that you can you find out when this regressed?
> 


It worked o.k. in the built from January 3rd but it is broken in the built from January 5th.

Does that help?

Comment 9

[Stefan [:stefanh]]

> Does that help?

Yes, thanks. That made investigate a bit more:

Works with 2006010410 (in the 2006-01-04-11 dir)

Does not work with 2006010510 (in the 2006-01-05-12 dir)

Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-01-04+10%3A00%3A00&maxdate=2006-01-05+12%3A00%3A00&cvsroot=%2Fcvsroot

Hmm... Bug 311028 deals with print stuff and is SeaMonkey-specific. I don't know if/how it could be related to the function of the native Mac print/Page setup dialogs, though.

Comment 10

[Ian Neal]

Attachment: Mac only fix to page setup v0.1 (Checked in trunk & branch 1.8.1)

This patch:
* Saves "native" page setup data

Comment 11

[Ian Neal]

Reporter: can you test this patch?

Comment 12

[Gulliver]

(In reply to comment #11)
> Reporter: can you test this patch?
> 


Ian,

how do I do this?

Comment 13

[Ian Neal]

Not sure on a Mac but usually involves patching Jar files. Stefanh, can you advise?

Comment 14

[Stefan [:stefanh]]

(In reply to comment #13)
> Not sure on a Mac but usually involves patching Jar files. Stefanh, can you
> advise?
> 

Sure. Gulliver, you need to patch printing.js in your chrome directory.
I'm sure there are easier ways to do this, but I always do everything by hand. Iirc there is an application called "Patch Maker" - not sure if it works on Mac, though.

I usually patch the file in my tree, and then I replace the appropiate file in the chrome dir. If you don't have a source tree, you'll have to change the file by hand (I never used patch to change something outside the tree, Ian might be able to help here). More precisely, you have to apply the same  changes to printing.js as the patch in attachment #209964 [details] [diff] [review] does.

To find  printing.js (do this on a build that you're not using - you might destroy everything if you're doing something wrong):

1) Right-click on the SeaMonkey app icon and select "Show package contents".
2) Navigate to 'Contents/MacOS/chrome'
3) Find the 'comm.jar' file and unpack it. You can do this by changing the name to comm.zip and just double-click on it.
4) Find the 'contents' folder (the unpacked comm.zip package)
5) Make changes to printing.js in content/communicator (or copy a already changed printing.js into the folder.
6) Navigate back to the chrome directory and repack the 'contents' folder - zip it without compression and re-name it to 'comm.jar')
7) Start SeaMonkey. Unless you have done anything wrong (like re-named a folder or messed with the folder hierarcy) you should be fine.

Comment 15

[Gulliver]

(In reply to comment #14)
> (In reply to comment #13)
> > Not sure on a Mac but usually involves patching Jar files. Stefanh, can you
> > advise?
> > 
> 
> Sure. Gulliver, you need to patch printing.js in your chrome directory.
> I'm sure there are easier ways to do this, but I always do everything by hand.
> Iirc there is an application called "Patch Maker" - not sure if it works on
> Mac, though.
> 
> I usually patch the file in my tree, and then I replace the appropiate file in
> the chrome dir. If you don't have a source tree, you'll have to change the file
> by hand (I never used patch to change something outside the tree, Ian might be
> able to help here). More precisely, you have to apply the same  changes to
> printing.js as the patch in attachment #209964 [details] [diff] [review] [edit] does.
> 
> To find  printing.js (do this on a build that you're not using - you might
> destroy everything if you're doing something wrong):
> 
> 1) Right-click on the SeaMonkey app icon and select "Show package contents".
> 2) Navigate to 'Contents/MacOS/chrome'
> 3) Find the 'comm.jar' file and unpack it. You can do this by changing the name
> to comm.zip and just double-click on it.
> 4) Find the 'contents' folder (the unpacked comm.zip package)
> 5) Make changes to printing.js in content/communicator (or copy a already
> changed printing.js into the folder.
> 6) Navigate back to the chrome directory and repack the 'contents' folder - zip
> it without compression and re-name it to 'comm.jar')
> 7) Start SeaMonkey. Unless you have done anything wrong (like re-named a folder
> or messed with the folder hierarcy) you should be fine.
> 

Stefan,

thanks a lot for these excellent instructions! Followed them step-by-step and it DOES work! This patch seems to fix the problem.

Comment 16

[Samuel Sidler (old account; do not CC)]

Since this only happens on the trunk, isn't the target for SeaMonkey 1.5alpha?

Comment 17

[Ian Neal]

(In reply to comment #16)
> Since this only happens on the trunk, isn't the target for SeaMonkey 1.5alpha?
> 
As bug 311028 was also checked in the 1.8 branch (but not the 1.8.0 branch), the target is correctly set to SeaMonkey 1.1alpha.

Comment 18

[Gulliver]

(In reply to comment #17)
> (In reply to comment #16)
> > Since this only happens on the trunk, isn't the target for SeaMonkey 1.5alpha?
> > 
> As bug 311028 was also checked in the 1.8 branch (but not the 1.8.0 branch),
> the target is correctly set to SeaMonkey 1.1alpha.
> 

Ian,

what happened to your fix? Why is it not in the nightlies? 

Comment 19

[Ian Neal]

(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > Since this only happens on the trunk, isn't the target for SeaMonkey 1.5alpha?
> > > 
> > As bug 311028 was also checked in the 1.8 branch (but not the 1.8.0 branch),
> > the target is correctly set to SeaMonkey 1.1alpha.
> > 
> 
> Ian,
> 
> what happened to your fix? Why is it not in the nightlies? 
> 
It is awaiting review and cannot be checked in without the correct reviews and approvals.

Comment 20

[Gulliver]

(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > (In reply to comment #16)
> > > > Since this only happens on the trunk, isn't the target for SeaMonkey 1.5alpha?
> > > > 
> > > As bug 311028 was also checked in the 1.8 branch (but not the 1.8.0 branch),
> > > the target is correctly set to SeaMonkey 1.1alpha.
> > > 
> > 
> > Ian,
> > 
> > what happened to your fix? Why is it not in the nightlies? 
> > 
> It is awaiting review and cannot be checked in without the correct reviews and
> approvals.
> 

Oh, I see! Thank you and let's hope that this valuable fix makes it into the nightlies soon!

Comment 21

[Polly]

> > > 
> > > Ian,
> > > 
> > > what happened to your fix? Why is it not in the nightlies? 
> > > 
> > It is awaiting review and cannot be checked in without the correct reviews and
> > approvals.
> > 
> 
> Oh, I see! Thank you and let's hope that this valuable fix makes it into the
> nightlies soon!
> 

I hope the printing problem can be fixed soon. I've been seeing "an unknown error occurred while printing" for the last few weeks but only noticed now, as I read this bug report, that Page Setup doesn't come up AT ALL!  I've not seen printing problems with Safari or IE.

Not being able to print is getting old fast.  The last few days I HAVE been able to print PDFs (using the Schubert plug-in), but still not regular pages. SeaMonkey crashes after spooling the pages to the printer driver. 

As I recall, when the problem first occured I'd been printing PDFs and then couldn't print anything. So maybe I have a different problem having to do with the plug-in getting corrupted. Hmm. But that wouldn't affect the page setup would it? Setup does work on mine through the Schubert plug-in (tiny arrow at the top of the vertical scrollbar) so that could be a work-around, maybe, if the regular Page Setup is broken.

I'm using an old nightly: Build ID: 2006021110
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
running on an eMac with Sys 10.2.8. 
I don't know anything about trees or trunks or branches. You guys keep up the good work.

//Polly

Comment 22

[Stefan [:stefanh]]

> I hope the printing problem can be fixed soon. I've been seeing "an unknown
> error occurred while printing" for the last few weeks but only noticed now, as
> I read this bug report, that Page Setup doesn't come up AT ALL!  I've not seen
> printing problems with Safari or IE.

See bug 326363

Comment 23

[Mark Mentovai]

Comment on attachment 209964 [details] [diff] [review]
Mac only fix to page setup v0.1 (Checked in trunk & branch 1.8.1)

r=me.  I made this change in toolkit in bug 312763 after bug 267422 broke it.  (Shoulda checked that bug's dependencies when porting it to xpfe!)  Because my review feels slightly patchcestuous, I'm leaving the existing r? set as well.

Would you consider using the same variable name for the print settings service as I did in attachment 199872 [details] [diff] [review], to reduce unnecessary divergence between toolkit and xpfe implementations?

Comment 24

[Ian Neal]

(In reply to comment #23)
> (From update of attachment 209964 [details] [diff] [review] [edit])
> r=me.  I made this change in toolkit in bug 312763 after bug 267422 broke it. 
> (Shoulda checked that bug's dependencies when porting it to xpfe!)  Because my
> review feels slightly patchcestuous, I'm leaving the existing r? set as well.
> 
> Would you consider using the same variable name for the print settings service
> as I did in attachment 199872 [details] [diff] [review] [edit], to reduce unnecessary divergence between toolkit
> and xpfe implementations?
> 
I actually have a patch, attachment 214037 [details] [diff] [review], waiting for review that changes the variable name in toolkit to be the same as the one here ;-)

Comment 25

[Mark Mentovai]

(In reply to comment #24)
> I actually have a patch, attachment 214037 [details] [diff] [review] [edit], waiting for review that
> changes the variable name in toolkit to be the same as the one here ;-)

Aha!  WFM!

Comment 26

[Ian Neal]

Comment on attachment 209964 [details] [diff] [review]
Mac only fix to page setup v0.1 (Checked in trunk & branch 1.8.1)

Checking in (trunk)
printing.js;
new revision: 1.12; previous revision: 1.11
done

Comment 27

[Ian Neal]

Comment on attachment 209964 [details] [diff] [review]
Mac only fix to page setup v0.1 (Checked in trunk & branch 1.8.1)

Requesting a= for SM1.1 as fix for bug 311028 went into branch 1.8.1 and this is needed to fix the regression there too.

Comment 28

[Robert Kaiser]

Comment on attachment 209964 [details] [diff] [review]
Mac only fix to page setup v0.1 (Checked in trunk & branch 1.8.1)

a=me for SeaMonkey 1.1

Comment 29

[Ian Neal]

Comment on attachment 209964 [details] [diff] [review]
Mac only fix to page setup v0.1 (Checked in trunk & branch 1.8.1)

Checking in (branch 1.8.1)
printing.js;
new revision: 1.7.4.3; previous revision: 1.7.4.2
done