There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:agashlin, could you have a look please?

I wanted to run this by Matt again with more data:

I was concerned about the delay this introduces into the uninstaller if the BITS service wasn't yet running. I checked on the quantum reference Acer notebook, uninstall takes 1.3-2.5s if BITS was running, and 6-7.2s if it has to start (over 5 runs). So this costs roughly 5 seconds.

I had brought this up during review when I'd only timed it on my faster notebook, where it adds about 2 seconds. It seems that the delay depends on the machine, probably mostly disk speed, so it could get worse on slower or heavily loaded machines. Though I expect the file removal will be proportionally slower as well.

Is this acceptable? I could possibly start the service in the background when the uninstall wizard starts (before interaction) to mask the latency somewhat. But I don't know if it's worthwhile for a rarely used interaction.

That does scare me a bit; I don't like the idea that the delay appears to be unbounded. I definitely don't want to start doing anything until the actual uninstall starts happening, but starting this in the background right then while the rest of the uninstall runs would be great.

Is there any way that we could set this operation going and then not have to wait for it to finish before the uninstaller exits? That seems like the ideal if it's possible, but I have no idea if it would be.

(In reply to Matt Howell (he/him) [:mhowell] from comment #4)

That does scare me a bit; I don't like the idea that the delay appears to be unbounded. I definitely don't want to start doing anything until the actual uninstall starts happening, but starting this in the background right then while the rest of the uninstall runs would be great.

I wasn't suggesting performing any operations before the uninstall begins, just kicking off the service start. Then when the job cancellation comes along near the end of the uninstall BITS will be already loaded (or will have at least started loading). (Or maybe that is what you were objecting to?)

Is there any way that we could set this operation going and then not have to wait for it to finish before the uninstaller exits? That seems like the ideal if it's possible, but I have no idea if it would be.

The problem is that we need to be able to enumerate jobs and cancel them once the service comes up, the delay is all up front. We might be able to spin off a script using BITSAdmin to do this, but I don't know exactly how and how fragile the result would be.

(In reply to Adam Gashlin [:agashlin] from comment #5)

I wasn't suggesting performing any operations before the uninstall begins, just kicking off the service start. Then when the job cancellation comes along near the end of the uninstall BITS will be already loaded (or will have at least started loading). (Or maybe that is what you were objecting to?)

I see, I was misunderstanding. Sounds like that may be our only option for making this any better; can I ask you to look into this one?

The problem is that we need to be able to enumerate jobs and cancel them once the service comes up, the delay is all up front. We might be able to spin off a script using BITSAdmin to do this, but I don't know exactly how and how fragile the result would be.

Got it, thanks. Let's not do anything that we're that unsure about.

https://hg.mozilla.org/mozilla-central/rev/f6230d38f6ef