Closed Bug 522216 Opened 10 years ago Closed 10 years ago

Print Preview creates unwanted PDF file on Desktop


(Core Graveyard :: Widget: OS/2, defect, major)

Not set


(status1.9.2 beta2-fixed, status1.9.1 .6-fixed)

Tracking Status
status1.9.2 --- beta2-fixed
status1.9.1 --- .6-fixed


(Reporter: losepete, Assigned: mozilla)




(Keywords: fixed1.9.0.16)


(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv: Gecko/20090924 SeaMonkey/2.0pre
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv: Gecko/20090924 SeaMonkey/2.0pre

I used Print Preview to see how a page would(should?) look printed.

I Closed the Print Preview without Printing.

This resulted in a seamonkey*.PDF file being created on the Desktop. This should only happen when selecting to Print the Preview.

Reproducible: Always

Steps to Reproduce:
1. open a url
2. select Print Preview
3. close  Print Preview
Actual Results:  
seamonkey*.PDF file created on Desktop

Expected Results:  
NO seamonkey*.PDF file created on Desktop
Yes, this is a apparently a major bug, probably somewhere in widget/src/os2/nsDeviceContextSpecOS2.cpp. It is likely present in 1.9.0, 1.9.1, 1.9.2, and trunk.
Assignee: nobody → mozilla
Severity: normal → major
Component: General → Widget: OS/2
Ever confirmed: true
Product: SeaMonkey → Core
QA Contact: general → os2
Version: unspecified → Trunk
Attached patch fix (obsolete) — Splinter Review
Quick fix for this problem (still wondering how this could go unnoticed for so long).
Assignee: mozilla → mozilla
Attachment #406329 - Flags: review?(mozilla)
Can we remove the printf? Also, can't we at least create the file somewhere other than the Desktop (temp dir)
I imagine the printf was some cheap, harmless debugging.  However, I think sticking the PDF in a temp directory instead of the desktop would be a big mistake.  The user has to open it to print it, and it should be easy to find...
Attached patch without printfSplinter Review
Now without the printf. I chose the Desktop exactly for the reason Steve pointed out.

After asking you for review I realized that you had probably never seen this code before. I am not proud of it, but it's the only way I found that we could print at all without hanging the machine or crashing the browser. It was supposed to be a temporary workaround, but it turns out that still nobody knows how to fix the hang/crash problem when printing through cairo. So the PDF file is our best bet. (I have a patch in the works, for months already, that creates a temporary PS file and then feeds that directly to PSCRIPT or eCups printers.)
Attachment #406329 - Attachment is obsolete: true
Attachment #406652 - Flags: review?(mozilla)
Attachment #406329 - Flags: review?(mozilla)
Comment on attachment 406652 [details] [diff] [review]
without printf

Looks good.

And I do remember this code. I'd forgotten that a PDF is the only way to print.
Attachment #406652 - Flags: review?(mozilla) → review+
Minor change to an OS/2-only file, so I pushed it to all relevant branches right away:

1.9.0 (CVS):
Checking in widget/src/os2/nsDeviceContextSpecOS2.cpp;
/cvsroot/mozilla/widget/src/os2/nsDeviceContextSpecOS2.cpp,v  <--  nsDeviceContextSpecOS2.cpp
new revision: 1.61; previous revision: 1.60
Closed: 10 years ago
Keywords: fixed1.9.0.16
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.