Closed
Bug 97707
Opened 23 years ago
Closed 22 years ago
Mac: path for "Open with" still remembered [using "Choose"], until restarting
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: bugzilla, Assigned: mscott)
References
Details
(Keywords: platform-parity, regression)
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].
Reporter | ||
Updated•23 years ago
|
Blocks: 78106
Keywords: pp,
regression
Reporter | ||
Comment 1•23 years ago
|
||
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].
Keywords: mozilla0.9.4
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?
Reporter | ||
Comment 4•23 years ago
|
||
dave, i think you're seeing bug 88287 [not being able to thoroughly remove the
helper app listing from the prefs panel]...
Reporter | ||
Comment 6•23 years ago
|
||
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.
Summary: Mac: after Reset, path for "Open with" still remembered [using "Choose"] → Mac: path for "Open with" still remembered [using "Choose"], until restarting
Reporter | ||
Updated•23 years ago
|
Component: XP Apps: GUI Features → File Handling
Keywords: mozilla0.9.4
Reporter | ||
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 7•22 years ago
|
||
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?
Reporter | ||
Comment 8•22 years ago
|
||
looks fine with 2003.02.18 trunk bits on OS X 10.2.4.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•