we are already done with the download. Break apart
SaveTodisk and LaunchWithTempFile into to separate
methods. never try to really open or save to disk
until we are sure we've brought up the progress window.
Bug #61947 --> pass in the initial time when we started the download via getDownloadInfo so
the progress dialog can use this information.
sr=sspitzer
entry for this mime type.
Bug #57364 --> look up content type to file extension mappings using the windows mime registry.
Bug #65872 --> if we get a content type of unknown or octet, try to ignore that content type
and extract the extension from the url and looking that up to see if we can get a better
content type.
sr=sspitzer
and force any Refresh urls back through the original window
context that initiated the helper app download. This solves
the problem where the user clicks on a link to download
content (either to disk or to a helper app) and that document
contains both a redirect for the actual content and a REFRESH
header which is used to point at a page the content provider
wants to see after the download is complete.
sr=rpotts, r=sspizter
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
and a docshell load tye. Unify nsIURILoadCommand and nsIDocShellLoadType enums so they
can be treated as the same type. This allows the uriloader to pass the correct load info
from the docshell that originates the load over to the docshell that actually
ends up loading the url.
r=radha, sr=rpotts
some bad debugging code that was left in mimetypes.rdf for pdf back in beta2
for now, return an error. This will make use ignore this entry in the data source
when performing mime lookups....which is good 'cause that will have a side
effect of making application/pdf content work again.
r=sspitzer, a=alecf
after we show the helper app dialog. So progress and load information is
now retargeted to a stand alone window instead of re-using the underlying
browser / mail window...In order to do this, the external app handler needed to implement nsIURIContentListener.
sr=r=rpotts
+ 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
UI up from the uriloader. This allows us to properly use a string bundle
for text in the dialog. this is prep work for the real fix for this bug.
r=law
mkaply%us.ibm.com
mscott%netscape.com
pchen%netscape.com
rpotts%netscape.com
cls%seawood.org
warren%netscape.com
pollmann%netscape.com
valeski%netscape.com
dougt%netscape.com
rayw%netscape.com
scc%mozilla.org