If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Helper Apps Decision Tracking



17 years ago
13 years ago


(Reporter: johng, Assigned: Bill Law)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][PDTP2][rtm+])



17 years ago
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

17 years ago
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)
Depends on: 45198
Keywords: nsbeta3
Priority: P3 → P1
Whiteboard: [nsbeta3+]

Comment 2

17 years ago
spam: cc self

Comment 3

17 years ago
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 

This is bug 51018 (currently nominated for nsbeta3).
Depends on: 51018

Comment 4

17 years ago
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).
Depends on: 35956, 50420

Comment 5

17 years ago
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.
Depends on: 22861

Comment 6

17 years ago
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

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

Comment 8

17 years ago
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

17 years ago
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?
Depends on: 43585, 50914

Comment 10

17 years ago
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

17 years ago
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.


17 years ago
Depends on: 53243

Comment 12

17 years ago
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.
Priority: P1 → P2
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]

Comment 13

17 years ago
Let's move this tracking bug into RTM.
Keywords: rtm
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3-][PDTP2][rtm+]

Comment 14

17 years ago
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

17 years ago
nav triage team:
All of the dependent bugs are either closed or under control, so closing this
tracking bug.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 16

17 years ago
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. 
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.