Closed Bug 522216 Opened 10 years ago Closed 10 years ago
Print Preview creates unwanted PDF file on Desktop
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:126.96.36.199pre) Gecko/20090924 SeaMonkey/2.0pre Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:188.8.131.52pre) 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
Status: UNCONFIRMED → NEW
Component: General → Widget: OS/2
Ever confirmed: true
Product: SeaMonkey → Core
QA Contact: general → os2
Version: unspecified → Trunk
Quick fix for this problem (still wondering how this could go unnoticed for so long).
Assignee: mozilla → mozilla
Status: NEW → ASSIGNED
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...
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.)
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: http://hg.mozilla.org/mozilla-central/rev/8c379aa3c98f http://hg.mozilla.org/releases/mozilla-1.9.2/rev/f300d0e3b35b http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b1d5540c3ee6 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 done http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/widget/src/os2&command=DIFF_FRAMESET&file=nsDeviceContextSpecOS2.cpp&rev1=1.60&rev2=1.61&root=/cvsroot
You need to log in before you can comment on or make changes to this bug.