There are many different bugs around Helper Apps without any spec of exactly what we are going to do and what we are not going to do. We need a single bug to track all the others, and we need a plan for what minimum set of stuff we need to fix. assigning to bill law to search for all helper app related bugs and attach them to this one. You can reassign to johng when you add those bugs. cc'ing sol (since johng will be out of town for a week) and jar.

nav triage team: adding 45198 nsbeta3+, P1 (yes, we know that we don't normally + tracking bugs, but deal with it, we have our reasons)

spam: cc self

One problem is that clicking on a link (or pressing Stop) in the browser page that initiated the download (regardless of whether it was to open with a helper app or save to disk) cancels the download. The user receives no warning or notification. This is bug 51018 (currently nominated for nsbeta3).

Another problem relates to handling of gzip data. gzip data is automagically decompressed by necko. Previously (see bug 35956) Gagan added the capability to turn this off before opening a channel and I used that from the "stream transfer" code. The new "super helper app" Downloading dialog and Save To Disk code doesn't deal with this situation. It isn't clear whether the channel can be reset after it has already been read. Hopefully, it will be a simple matter of adding a SetApplyConversion(PR_FALSE) call. Worst case, we'll need to cancel the original channel load and initiate a new one. I suspect this problem might also be the cause of some of the "wrong file name" bugs (bug 50420 and dups).

The problem reported in bug 22861 is back. The "save to disk" mode of the new helper app thingy is not respecting the content-disposition http response header. I'm debating reopening that bug, but the problem is definitely there.

Another remaining issue is the deletion of the temporary files that get downloaded to the temp directory. I don't see where those are ever cleaned up. Also, if a file already exists in the temp directory with the same name (e.g., foo.bar), then the new file gets the name foo-1.bar. That's OK for temporary files to be opened by helper apps, but if you choose Save To Disk then the default file name should revert to the *real* file name.

Error handling needs to be improved (this applies to the stream transfer code, as well). See, for example, bugs 35161, 48620, and 50697.

Another problem from the past that has re-appeared: The last-saved-to directory is not remembered in prefs (and the saved value in prefs isn't used). There were lots of bugs on this till we got it working properly with the stream transfer and filepicker code. Those are all RESOLVED/VERIFIED by now. We should open a new bug so we can start fresh, I guess.

Adding bug 43585 and bug 50914 which you certainly want to track with this one. However, these are RFEs: bug 18219, bug 46739, and my input-helper-app bug 46135. Do you want to track those RFEs on this tracker?

Thank you for adding those first two. The other RFE's I'd prefer to not link from here because they're not nsbeta3 issues.

Update on bug 50420. After all was said and done, it turns out that we've got a problem that seems to hinge on the fact that our helper app launching strategy requires that we add certain file extensions to temporary files so that when we do ShellOpen(?) on 'em, the right helper app starts. If instead we're doing save-to-disk, we end up changing the extension to ".exe". We should probably not do that except on Windows. Probably not for application/octet-stream, and probably not when we're saving to disk.

Assuming helper apps can limp along and are no longer in stop ship state, pdt suggests P2 to help move the effort to crasher and even more critical bugs.

Let's move this tracking bug into RTM.

added bug 53243 which has not been confirmed yet. Perhaps someone could verify if this is an appropriate bug to attach to this tracker.

nav triage team: All of the dependent bugs are either closed or under control, so closing this tracking bug.

How are bug 35956 and bug 50420 under control? Wouldn't it be better to remove keyword(s) than closing this tracking bug? Those of us that want to dive into helper apps code would really get a great deal of help if this were kept current.