50326 - Helper Apps Decision Tracking

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P2)

Description

[johng]

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.

Comment 1

[johng]

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)

Comment 2

[sean echevarria]

spam: cc self

Comment 3

[Bill Law]

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).

Comment 4

[Bill Law]

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).

Comment 5

[Bill Law]

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.

Comment 6

[Bill Law]

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.

Comment 7

[Bill Law]

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

Comment 8

[Bill Law]

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.

Comment 9

[James Salsman]

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?

Comment 10

[Bill Law]

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.

Comment 11

[Bill Law]

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.

Comment 12

[clayton]

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.

Comment 13

[don]

Let's move this tracking bug into RTM.

Comment 14

[Brian Degenhardt]

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

Comment 15

[johng]

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

Comment 16

[James Salsman]

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.