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
git-svn-id: svn://10.0.0.236/trunk@87587 18797224-902f-48f8-a5cc-f745e15eee43
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
git-svn-id: svn://10.0.0.236/trunk@86717 18797224-902f-48f8-a5cc-f745e15eee43
use the status of the last request processed in loading the document to determine
success or failure. That's incorrect. Instead, test to see if the load group is being
canceled. If it is, use that as the status for the entire document. Otherwise, ignore
the status for the last request and instead use the status for the main document
(the default load channel).
sr=rpotts, r=sspitzer
git-svn-id: svn://10.0.0.236/trunk@81801 18797224-902f-48f8-a5cc-f745e15eee43
+ Added dummy function to all users of nsIWebProgressListener
+ Added new security event sink.
+ Hooked up new event sink to docloader and friends.
+ Fixed memory leaks and crashes in nsSecureBrowserImpl.
+ Added AlertPrompt to nsIPrompt Interface.
+ Enabling xpcom test on unix.
Fixes bug 46872. r=valeski/rpotts
git-svn-id: svn://10.0.0.236/trunk@79206 18797224-902f-48f8-a5cc-f745e15eee43
because we aren't told if the main document url is getting redirected or if a part (like an
image) is getting redirected. This caused the urlbar to get incorrectly updated.
r=sspitzer
git-svn-id: svn://10.0.0.236/trunk@77941 18797224-902f-48f8-a5cc-f745e15eee43
docloader...Fix viewer crash by returning aChannel instead of the
doc channel.
git-svn-id: svn://10.0.0.236/trunk@67026 18797224-902f-48f8-a5cc-f745e15eee43
through the web progress interfaces. In order to implement progress, the doc loader now implements
nsIProgressEventSink and receives events directly from the channels.
git-svn-id: svn://10.0.0.236/trunk@66879 18797224-902f-48f8-a5cc-f745e15eee43
I was signaling the stop notification via a OnchildStatus in this scenario. We should always signal the start
and stop of documents as a status change even if a child is originating the change.
git-svn-id: svn://10.0.0.236/trunk@66312 18797224-902f-48f8-a5cc-f745e15eee43
nsIWebProgressListener.
Right now, the only methods that are hooked up are signaling when the doc loader is busy loading a document and
when it is done loading a document.
git-svn-id: svn://10.0.0.236/trunk@64991 18797224-902f-48f8-a5cc-f745e15eee43
now that we don't leak the global doc loader, there are times when it gets destroyed b4 it's children during
the shutdown process.
r=sspitzer
git-svn-id: svn://10.0.0.236/trunk@63998 18797224-902f-48f8-a5cc-f745e15eee43
