2) Adds a couple of new methods and an attr to nsIWebBrowserPrint (navigate, is frameset, & exitPP)
3) Removes all but one method from nsIContentViewerFile.idl/h the remaining call is for print regression testing
4) Removes the "static" implementation of nsIContentViewerFile.h
5) Fixed up nsIContentViewerFile.idl and turned it back on so it is now generating the header file
6) Removed all uses of nsIContentViewerFile.h except for the WebCrawler (uses it for Printing Regression testing)
7) nsDocumentViewer.cpp now implements nsIWebBrowserPrint.idl this makes it easier to add new print functionality in one place
8) You can now ask an instance of the ContentViewer for a nsIWebBrowserPrint to do printing (it retruns the nsIWebBrowserPrint interface implemented by the nsDocumentViewer)
9) Anybody who was using nsIContentViewerFile to print will now use nsIWebBrowserPrint
10) You can now do a "GetInterface()" on a GlobalWindow for a nsIWebBrowserPrint
11) The browser UI now uses the GetInterface on the GlobalWindow to get a nsIWebBrowserPrint object to do printing and this can be used for all printing functionality
Bug 120622 r=dcone sr=waterson
Enabling XP Print Dialog for Windows
Enabling XP Print Progress Dialog
Enabling XP Page Setup Dialog
Fixing nsPrintPreviewContext to use nsIPrintPreviewContext
Bug 113917 r=dcone sr=attinasi
This removes all call-sites I can currently fix. Tomorrow I'll try to get someone to checkin my changes to security/ and I'll get some help with the Netscape side of things.
nsString::GetUnicode()'s final death-blow will be dealt soon. Please keep this in mind as you add new code :-)
Revising nsIChannel to allow for overlapped i/o. This consists of three parts:
1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.
This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.
r=darin@netscape.comsr=rpotts@netscape.com
1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.
This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.
The full details of the change on written up in the netlib newsgroup.
r=darin@netscape.comsr=rpotts@netscape.com
