Closed Bug 88330 Opened 24 years ago Closed 22 years ago

Edit Type dialog: "always ask before..." checkbox shouldn't be selected if deselected from helper app dialog

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.2alpha

People

(Reporter: bugzilla, Assigned: law)

References

Details

spun off from bug 88066 --found using a recent linux mozilla trunk build and mac
comm trunk bits from this morning. prolly also occurs on win32 [will test that
later on]...

see linux test (8) or mac test (8) in bug 88066, or this recipe:

0. make sure you have a helper app defined in mozilla/nscp6.x [it should of
course be listed in the Helper Applications pref panel]. eg, i have one for
audio/mpeg [for .mp3 files].
1. click on a link which would bring up the helper app dialog.
2. in the helper app dialog, deselect [turn off] the "Always ask before opening
this type of file" checkbox.
3. click OK and download the file. dismiss the download progress dialog [if you
have it set to persist] when done.
4. [optional] verify this setting by clicking the link again: the helper app
dialog shouldn't appear, although the download progress dialog would [unless you
have that turned off as well --different setting anyhow].
4. go to the Helper Applications pref panel, select the mimetype, and click the
Edit button.

observe: the checkbox for "Ask me before opening downloaded files of this type"
is still selected.

mscott says that he can fix this...along with turning the feature back on in the
commercial bits *and* getting rid of the useless "outgoing type" checkbox [see
bug 87713]. :)
kw-o-rama...
> 4 [optional] verify this setting by clicking the link again: the helper app
> dialog shouldn't appear

With build id 2001070916 on RedHat Linux 7.1, the downloading option dialog
always appears, no matter what I do. Please see my comments on bug 48948
(2001-07-10 12:00 and 2001-07-10 09:45) for more information.

This wast *not* the case with 0.9.2 
Blocks: 78106
Blocks: 79151
Blocks: 99230
not an emojo stopper.
Status: NEW → ASSIGNED
Keywords: nsbranchnsbranch-
Component: XP Apps → File Handling
Blocks: 107067
Keywords: nsbranch-
mscott: what's the status of this bug?  Our browser is really hard to use for
downloading stuff since we always have to go through two dialogs every time. 
Any chance we can get a fix, or at least a workaround (can I edit my prefs
somehow to set up certain types as always-download)?  Is there some way I can help?
Blocks: 113908
*** Bug 110345 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM. 
Decision was to assign this bug to law.
Assignee: mscott → law
Status: ASSIGNED → NEW
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.2alpha
QA Contact: sairuh → petersen
still an issue using 2003.01.13.08 (comm linux rh8.0).
sairuh, what exact steps to reproduce did you follow?  Was this with a clean
profile? If not, could you mail me your prefs.js (and mimeTypes.rdf) files?
chatted briefly w/boris about this. what i'm seeing is an old commercial issue
(see http://bugscape.mcom.com/show_bug.cgi?id=8825). it's not a problem on
mozilla afaict, so marking resolved.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified on the 2003-01-23-04 Mozilla trunk builds under Windows XP and OS X .
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.