All we need from downloads is the nsIDownload header, so that's an easy way to use one less bit of xpfe. This switches what we build and include, and makes the minor changes necessary to bring us in line with the toolkit changes to nsIDownload. mento, I have no idea if that's the best way to opt us out of that part of xpfe, so suggestions are welcome if not.

Comment on attachment 287183 [details] [diff] [review] fix >Index: toolkit/components/Makefile.in > ifeq ($(MOZ_BUILD_APP),camino) > DIRS += autocomplete/public >+DIRS += downloads/public > endif There's no reason to have two DIRS lines here. You can put both of these directories on the same line, or you can keep them on two lines but break them up with a \. I can only give superreview in mozilla/camino (and I do here), but you've got non-Camino bits in this patch, so I'm marking this r=me. Since the only non-Camino bits are build config, my review there is sufficient too, build config shouldn't require superreview.

Landed on trunk.

Unlanded; I completely forgot things currently need approval for trunk landing :(

Moving to Toolkit:Build Config since I'm told the approval request is unlikely to be noticed otherwise.

That thing about approval requests going unnoticed unless they are in certain components/products is IMHO absolutely ridiculous, but unfortunately we have it currently, yes :(

just fyi, we moved nsIDonwload to xpfe because we were changing nsIDownload, and there may be more changes down the line...

I should rephrase what I said last time. I won't feel bad if we break you guys on accident since you are using toolkit's nsIDownload but not the download manager backend.

(In reply to comment #7) > I won't feel bad if we break you guys on accident Noted, but with all the eagerness to rip xpfe out of the tree, I don't see that we have a lot of choice in the short term. Landed on trunk.