281130 - rename NS_DOWNLOAD_CONTRACTID to NS_TRANSFER_CONTRACTID

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

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: <[e-mail]> and the thread following it (private mail)

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

http://lxr.mozilla.org/mozilla/search?string=download_contrac for my reference

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

(plus http://lxr.mozilla.org/seamonkey/search?string=download%3B1 )

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

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 5

[Boris Zbarsky [:bzbarsky]]

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 6

[Darin Fisher]

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?

Comment 7

[Darin Fisher]

> let me know if you think I should remove it :-)

Yeah, I vote for removing it.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

ok. checked in, without the download;1 compat code.