Last Comment Bug 522216 - Print Preview creates unwanted PDF file on Desktop
: Print Preview creates unwanted PDF file on Desktop
: fixed1.9.0.16
Product: Core Graveyard
Classification: Graveyard
Component: Widget: OS/2 (show other bugs)
: Trunk
: x86 OS/2
-- major (vote)
: ---
Assigned To: Peter Weilbacher
pick a url yourself to test
Depends on:
  Show dependency treegraph
Reported: 2009-10-14 03:27 PDT by Peter Brown
Modified: 2014-12-09 11:27 PST (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

fix (1.62 KB, patch)
2009-10-14 15:43 PDT, Peter Weilbacher
no flags Details | Diff | Splinter Review
without printf (1.68 KB, patch)
2009-10-16 01:10 PDT, Peter Weilbacher
mozilla: review+
Details | Diff | Splinter Review

Description User image Peter Brown 2009-10-14 03:27:43 PDT
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
Comment 1 User image Peter Weilbacher 2009-10-14 06:08:12 PDT
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.
Comment 2 User image Peter Weilbacher 2009-10-14 15:43:34 PDT
Created attachment 406329 [details] [diff] [review]

Quick fix for this problem (still wondering how this could go unnoticed for so long).
Comment 3 User image Mike Kaply [:mkaply] 2009-10-15 14:23:27 PDT
Can we remove the printf? Also, can't we at least create the file somewhere other than the Desktop (temp dir)
Comment 4 User image Steve Wendt 2009-10-15 20:45:06 PDT
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...
Comment 5 User image Peter Weilbacher 2009-10-16 01:10:51 PDT
Created attachment 406652 [details] [diff] [review]
without printf

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 6 User image Mike Kaply [:mkaply] 2009-10-16 04:42:56 PDT
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.
Comment 7 User image Peter Weilbacher 2009-10-23 05:02:08 PDT
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

Note You need to log in before you can comment on or make changes to this bug.