is a mailto url. why? because it works so well for mailto =). No sense
in only allowing people turning uri dispatching on to get the benefits.
r=travis.
CanHandleContent now has an out parameter for desired content type.
Minor re-write of uri loder logic to incorporate stream conversion. If the content listener passes back
a desired content type that is different from the content type that we asked it to handle, we'll
automatically invoke a stream converter. This allows a doc shell which wants to handle say message/rfc822
to request that content be in the form of text/xul (i.e. if it was presenting the content).
Revamp the uri loader to excusively use AsyncRead instead of AsyncOpen and AsyncRead. With these changes,
we now only need to add the ability to retarget to our protocol channels instead of requiring both
retargeting and AsyncOpen support.
In order to do this, the DocumentOpenInfo object needed to become a nsIStreamListener instead of just
a stream observer.
Clean up OpenURI api. get rid of the verb, the channel context and the loadgroup as required arguments
to OpenURI.
Add nsUriLoaderEventSinkGetter class. Many method signatures
changed to match the changes to nsIURILoader::OpenURI.
Clean up OpenURI api. get rid of the verb, the channel context and the loadgroup as required arguments
to OpenURI.
Add the notion of a open uri context as an in and an out parameter. The open uri context is a cookie which
the caller can later give back to the uri loader when running another url in the same context. It's an ISupports
right now and the type should be opaque to the caller.
Don't require the caller to pass in an event sink getter. We can generate this for them. Do give them the ability
to pass in a nsIProgressEventSink. Note: this parameter is actually going to get changed into a nsIProgressListener
real soon as well. So don't get to used to it.
GetProtcocolHandler needs to pass in the uri we are trying to open so the
listener can pick an appropriate p.h. based on the protocol of the uri. (if
they so choose).
1) add OpenURIVia support.
2) reimplent DispatchContent so we ask the listener if it can handle the content. Then when (if) we find
a content listener that can handle it, call DoContent.
3) if we can't find a content listener, go to the registry and try to find a registered content handler.
This part isn't finished as eventually i need to be going to the category manager instead of forming
the progid for the content handler myself.
Add notion of CanHandleContent. This is supposed to be a light weight method for the implementor
such that the uri loader can ask right off the top if the listener can handle a particular content
type. If it can, then later on, the uir loader may call DoContent to actually handle it.
remove CanHandleConent. I don't think we need this. Also remove notion of getting a parent
content handler. This doesn't make sense anymore for how I'm defining a content handler.
Added progid prefix for content handler.
define and implement nsDocumentOpenInfo. Implement uri loader::OpenURI. This is the first pass at
my implementation it isn't complete and it doesn't use the registry for getting
protocol handlers and content handlers yet...but it's a start
expanded OpenURI interface to take all the required arguments we need in order to really open the uri.
This includes adding the command, window target, event sink getter, load group and channel context.
Added dispatchContent method which is used by the doc open info's to talk back to the uri loader.
DispatchContent takes an opened channel and the uri content listener.
doContent now returns a boolean called abortProcess. if the listener wants to handle the content without
returning a stream listener, i.e. it wants the uri loader to stop doing anything else with this content,
then it returns true for abort process.
mscott%netscape.com
rpotts%netscape.com
dp%netscape.com
mcafee%netscape.com
warren%netscape.com
valeski%netscape.com
tbogard%aol.net
dmose%mozilla.org