since the interfaces it describes are generic ones, and gecko may want to use it for uploads at some point, the contractid should refer to transfers rather than downloads. (both the string and the #define name) references: bug 241082 comment 12 Message-Id: <41DD5AEC.firstname.lastname@example.org> and the thread following it (private mail)
http://lxr.mozilla.org/mozilla/search?string=download_contrac for my reference
Created attachment 173536 [details] [diff] [review] patch
12 years ago
I should note: this patch keeps binary compat w/ 1.8alpha6, as it still looks for @mozilla.org/download;1 if @mozilla.org/transfer;1 is not found. but the IID of this interface changed in alpha6. so this is not really compatible with versions before that. so... maybe this compat code (two lines) is not useful? let me know if you think I should remove it :-)
Comment on attachment 173536 [details] [diff] [review] patch r=bzbarsky, but could we file bugs on all the header sniffer impls that use HEAD, similar to the bug we have filed on Firefox?
Comment on attachment 173536 [details] [diff] [review] patch >Index: uriloader/exthandler/nsExternalHelperAppService.cpp >+ nsCOMPtr<nsITransfer> tr = do_CreateInstance(NS_TRANSFER_CONTRACTID, &rv); >+ // Using the old contractid for compatibility (pre-1.8beta) >+ if (NS_FAILED(rv)) >+ tr = do_CreateInstance("@mozilla.org/download;1", &rv); But, hasn't nsITransfer changed? What's the point in supporting the old ContractID if the interface won't be supported, or are you thinking that this might keep some JS implementations limping along?
> let me know if you think I should remove it :-) Yeah, I vote for removing it.
ok. checked in, without the download;1 compat code.