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

VERIFIED FIXED in mozilla1.2alpha


Core Graveyard
File Handling
17 years ago
2 years ago


(Reporter: sairuh (rarely reading bugmail), Assigned: Bill Law)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




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

Comment 1

17 years ago
Keywords: mozilla0.9.3, nsBranch

Comment 2

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


17 years ago
Blocks: 79151


17 years ago
Blocks: 99230

Comment 3

17 years ago
not an emojo stopper.
Keywords: nsbranch → nsbranch-


17 years ago
Component: XP Apps → File Handling


17 years ago
Blocks: 107067


17 years ago
Keywords: nsbranch-

Comment 4

16 years ago
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?


16 years ago
Blocks: 113908

Comment 5

16 years ago
*** Bug 110345 has been marked as a duplicate of this bug. ***


16 years ago
Keywords: nsbeta1

Comment 6

16 years ago
Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM. 
Decision was to assign this bug to law.
Assignee: mscott → law

Comment 7

16 years ago
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha


16 years ago
QA Contact: sairuh → petersen

Comment 8

15 years ago
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?

Comment 10

15 years ago
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.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 11

15 years ago
Verified on the 2003-01-23-04 Mozilla trunk builds under Windows XP and OS X .
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.