ran into this while testing with bug 93173 --it occurs both on Mac OS 9.1 and OS X [10.0.4], 2001.08.30.05-comm. in a way, it reminds me of bug 88287 --except that i'm not trying to remove a user-defined helper app: it seems that the application path set in "open with" [using "choose"] is still remembered when it shouldn't be. let me know if this is just another variation of 93173 or 88287, and i'll dup it as such. recipe: 1. went to ftp://ftp.mozilla.org/pub/mozilla/nightly/ and chose a dir that had a .bz2 file, and clicked on that link. [since the other types on http://mozilla.org had predefined types.] 2. the helper dialog has "save as" selected. select "open with" and then chose StuffIt Expander to handle it. [note: if you're running commercial, you might encounter bug 91021, which prevents selection of a carbonized app.] 3. deselect the "always ask..." checkbox. 4. click OK, and the app launches and opens the file. [note: app won't launch on OS X due to bug 97676.] 5. close the download progress dialog ["saving file" dialog]. 6. go to Helper App prefs and click on Reset. dismiss prefs. 7. click the .bz2 link again. expected results: the helper app dialog should display "Open <no application specified>" with "save to disk" selected. actual results: the helper app dialog somehow still displays the path to the application i had chosen in step 2, with "Open with [fullpath to Stuffit Expander]" selected. workaround: quitting and restarting the app clears this up. linux and win32: not a problem there [tested with 2001.08.29.xx-comm bits, due to various blockers in today's builds].

addendum: also saw this using 2001.08.30.05-mozilla bits on mac os x. correction on the classic build: used 2001.08.29.08-commercial bits on mac os 9.1 [emulated].

Come to think of it, I saw something similar on Linux, also while testing bug 93173 and then forgot all about it. In my case, I did the following: 1. clicked on a realaudio link at cdnow and got dialog. 2. Clicked "Advanced..." and configured helper app for realaudio. 3. Unchecked "always ask" box (which may be unnecessary) and launched the app 4. Opened prefs, selected the helper app I'd just added and hit "remove" 5. Hit OK to close prefs and clicked on link again, at which point I ran into bug 97658 6. I restarted the browser and, upon clicking the realaudio link again, realplay was launched and played the file. Upon opening prefs, the helper app was back even though I'd removed it. I'll try to test this again tomorrow when I can pull a build with the fix for bug 97658.

On 2001083109/Linux: bug 97658 is fixed but I'm still seeing the behavior I reported above. So, on Linux, removed helper apps return after browser restart. Would this be a new bug or the same as this one?

dave, i think you're seeing bug 88287 [not being able to thoroughly remove the helper app listing from the prefs panel]...

Yeah, you're right... sorry :-\

dave, you're right --deselecting "always ask..." isn't really relevant here. in fact, i'm not sure whether hitting the Reset button in the prefs panel is needed to illustrate this bug [other than being analogous to bug 88287]. it's just on the Mac that the full path of an app is remembered when it shouldn't be. clarifying summary. an even more simplified test case: 1. go to a link for which there's no predefined helper app. eg, either a .bz2 or .exe file. 2. in the helper app dialog, select the "open" radio button. 3. click "choose" button and select an application, eg, Stuffit Expander. 4. click OK --the file will be downloaded and the helper app launched. 5. dismiss the download progress dialog. 6. click the link again. expected results: the helper app dialog should display "Open <no application specified>" with "save to disk" selected. actual results: the helper app dialog somehow still displays the path to the application i had chosen in step 3. workaround: quit and restart the app.

I don't think this bug is valid at this point after the checkin for Bug 86640. There is no longer a 'Reset' button in the Helper Applications dialog. Reporter - can you confirm?

looks fine with 2003.02.18 trunk bits on OS X 10.2.4.