Closed Bug 324141 Opened 15 years ago Closed 15 years ago

Cannot change paper orientation in page setup dialogue

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey1.1alpha

People

(Reporter: gulliver, Assigned: iann_bugzilla)

References

Details

(Keywords: fixed-seamonkey1.1a, fixed1.8.1, regression)

Attachments

(1 file)

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
Assignee: general → printing
Component: General → Printing
Product: Mozilla Application Suite → Core
QA Contact: general
Version: unspecified → Trunk
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).
Keywords: regression
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.)
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"?
Does this happen in Fx trunk builds as well? Or is this a Sm-only regression?

(Oh, and confirming)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Gulliver, is there any chance that you can you find out when this regressed?
(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. 
(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?
> 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.

Component: Printing → General
Product: Core → Mozilla Application Suite
Target Milestone: --- → seamonkey1.1alpha
Assignee: printing → general
QA Contact: general
This patch:
* Saves "native" page setup data
Assignee: general → iann_bugzilla
Status: NEW → ASSIGNED
Attachment #209964 - Flags: review?(mnyromyr)
Reporter: can you test this patch?
(In reply to comment #11)
> Reporter: can you test this patch?
> 


Ian,

how do I do this?
Not sure on a Mac but usually involves patching Jar files. Stefanh, can you advise?
(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.

Depends on: 311028
(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.

Since this only happens on the trunk, isn't the target for SeaMonkey 1.5alpha?
(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.
(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? 
(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.
(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!
Blocks: 327492
No longer blocks: 327492
> > > 
> > > 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
> 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
Depends on: 326363
No longer depends on: 326363
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?
Attachment #209964 - Flags: review+
(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 ;-)
(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!
Attachment #209964 - Flags: review?(mnyromyr) → review+
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
Attachment #209964 - Attachment description: Mac only fix to page setup v0.1 → Mac only fix to page setup v0.1 (Checked in trunk)
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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.
Attachment #209964 - Flags: approval-seamonkey1.1a?
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
Attachment #209964 - Flags: approval-seamonkey1.1a? → approval-seamonkey1.1a+
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
Attachment #209964 - Attachment description: Mac only fix to page setup v0.1 (Checked in trunk) → Mac only fix to page setup v0.1 (Checked in trunk & branch 1.8.1)
You need to log in before you can comment on or make changes to this bug.