Move printing code out of the docshell into its own file.

*** Bug 139906 has been marked as a duplicate of this bug. ***

This patch does the following: 1) breaks out all the printing related code and objects into there own files. A majority of the code that used to be local methods to the DocumentViewer are now local methods to the nsPrintEngine object. 2) It includes all changes to the DocumentViewer that have been checked in (so far) Most of these changes that go into the DocumentViewer now go into the nsPrintEngine 3) The other change is adding a PLEvent to for cleaning up the PrintEngine. There are time where the nsPrintObject needs to have itself deleted via the DV, so it schedules a PLEvent to do that. 4) Add nsIDocumentViewer interface so the PrintEngine could access methods in the DV without making it a friend or breaking out the DocumentViewer's header which would be too painful.

see comments for part #1 - this patch has all the new files in it

Small change for problem found while doing additional testing

Comment on attachment 94390 [details] [diff] [review] patch part 2 looks good to me. r=dcone

alot of testing would be a good thing for this.. which rod confirmed he did.

Comment on attachment 94457 [details] [diff] [review] patch Part 1 (v2) sr=jst

Comment on attachment 94390 [details] [diff] [review] patch part 2 Shouldn't nsIDocumentViewerPrint.h live in content/base/public and not in .../src? Other than that, sr=jst

nsbeta1+

fixed

I don't see any change to the content.xml mac project file? Are we just waiting for the tree to go red?

Oh, and nsIDocumentViewerPrint.h was checked in in content/base/src despite sr's comment.

I should have mentioned in the bug that we exchanged email and decided it was ok for now to be in the src directory because nobody should really be using it other then the nsPrintEngine.cpp. The only reason it was created was because the header for the DV would be extremely difficult to break out seprartely.

Why in the world did this go in content/base/src/? nsDocumentViewer never should have been there in the first place --- why are we propagating the mistake?

it's current location wasn't up to me

This broke copying of image location (bug 163897). When the code was moved, the call to GetImageLocation() was changed to GetLinkLocation().

This also allegedly broke the ability to close print preview (bug 164384). Not good, and we need help fixing that bug for 1.2alpha. /be

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html