remove protocol scheme check before using the uri loader. this
means that all urls will run through the uriloader regardless of
type when it gets turned on.
webshell:
doContent and canHandleContent now take a nsURILoaderCommand
modify the handle link click event method to pass in
in the nsIURILoader::viewUserClick command to the uri loader
r=travis
// to distinguish between incoming urls that are a result of user
// clicks vs. normal views, view source and requires new window
nsIURIContentListener.idl--> doContent and canHandleContent now take a nsIURILoadCommand enum
nsURILoader.cpp --> changes to account for load command enum.
AsyncRead pass in the window context as the url context
(waterson will need this for his chrome cache work)
if we can't find a content handler for the content then go
back to the original window that loaded the url and force
them to handle the content...this is a HACK to force us to run
through the old code path for handling unknown content types
until the new version is online.
r=travis
- get rid of GetAccountManager call (it's now a service)
- move hacks GetCurrentIdentity and GetCurrentServer into the account manager for now
- eliminate these calls from nsMsgMailSession
- update all call sites (C++ and JS)
r=mscott
reorganizing/splitting protocol handler methods, though not yet adding any
new functionality:
Allow for multiple instances of nsHTTPResponse to be associated
with the same connection, i.e. so that response headers from the
cache and response headers from the server can coexist
simultaneously. To wit:
Moved content-length, charset and content-type information
from nsHTTPChannel into nsHTTPResponse
Split into separate functions the accumulation of a single line of
HTTP header data (from the input stream) and the parsing of
that line. This permits cached response headers and server
response headers to be parsed from separate data sources, the
latter arriving from a nsIBufferInputStream and the former
retrieved from the cache as a string.
Moved the newly-created header-parsing methods to
nsHTTPResponse from nsHTTPResponseListener
Fixed some bugs in the interaction between AsyncOpen and
AsyncRead. It was possible for an OnHeadersAvailable event to be
triggered *after* the associated OnDataAvailable, rather than the
other way around. It was also possible, in a rare case, for
mOpenObserver->OnStopRequest() to be called without ever having
called mOpenObserver->OnStartRequest(). I think my changes made
the logic a bit more foolproof.
Removed ancient ifdef NSPIPE2
mscott%netscape.com
alecf%netscape.com
cata%netscape.com
tbogard%aol.net
rgoodger%ihug.co.nz
mcafee%netscape.com
norris%netscape.com
sfraser%netscape.com
pavlov%netscape.com
beard%netscape.com
fur%netscape.com
pinkerton%netscape.com
briano%netscape.com
waldemar%netscape.com
rhp%netscape.com
warren%netscape.com
waterson%netscape.com
bryner%uiuc.edu
erik%netscape.com
ssu%netscape.com
ducarroz%netscape.com
cmanske%netscape.com