Closed Bug 48948 Opened 24 years ago Closed 21 years ago

downloading/opening options dialog doesn't save preferences ["Always show this dialog before handling files of this type"]

Categories

(Core Graveyard :: File Handling, defect, P2)

Product:
Core Graveyard
Component:
File Handling
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla0.9.9

People

(Reporter: joschi, Assigned: mscott)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(2 files)

my prefs.js file with this problem
23.48 KB, text/plain
Details
My mimeTypes.rdf file with this problem
3.10 KB, text/plain
Details 
the dialogue that aska: "this file has mime type...blah blah... can't be opened
with mozilla: (*) open using ( ) save to disk" has a "[x] Always ask me before
opening or saving files of this type."  when i untick that so it wont ask me
anymore, it doesn;t save this preference.
mscott, is this yours?
Assignee: asa → mscott
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yeah we didn't get to this in 6.0 =(. The preference isn't sticky.
I've disabled the ask me check box to avoid confusion andI already have a
future'd bug to track the implementation in a follow up release to ns6.
Unfortunately we just don't have time to properly implemement this setting.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
To disable checkbox is a temporary solution.
I think this should not be marked as FIXED.

This is a fairly major problem if you are retrieving documents that Mozilla does not handle internally (eg. trying to listen to M3U music streams).  This checkbox has to be enabled and be functional.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
mscott would you prefer to resummarize this bug to explain that it refered to 
disabling a box that didn't work?

reguardless, do you have the bug number for the actual feature implementation?

tylerv@san.rr.com: don't hit and run. It's not polite. If you're wrong you have 
mucked up a bug and the person who fixes it can't even tell you that you messed 
up.
Component: Browser-General → XP Apps: GUI Features
OS: Windows 98 → All
QA Contact: doronr → sairuh
Hardware: PC → All
Netscape Nav triage team: this is a Netscape beta stopper.  Adding law to the cc 
list.
Keywords: nsbeta1
Priority: P3 → P2
nav triage team:

Marking nsbeta1+
Whiteboard: nsbeta1+
mscott: can anyone in XPApps take this, we'd like to have this in mozilla0.8 or
0.9. thanks, Vishy
See also bug 52454 which I'm working on.  It covers the same basic feature.
I've outlined what I think needs to be fixed in that bug.  Some changes need to
be made to both the "front-end" dialogs and to the "back end"
(uriloader/exthandler code).
removing nsbeta1+ for the moment. Bill do you think your fix will get in in the
nsbeta1 time period?
Whiteboard: nsbeta1+
Bug 52454 is targeted for mozilla0.9.
should this be duped in favor of bug 79539, or [how] is this a separate issue?
Blocks: 78106
This can probably be resolved FIXED.  Mozilla users can uncheck that box and it
works.  A pref disables it in Netscape6.1.  Any other nits have separate bugs, I
think.
according to bug 84711 [if i'm understanding it properly], this still isn't
working.

nominate-o-rama.
Keywords: mozilla0.9.2, rtm, ui
Summary: download options dialogue doesn't save preferences → download options dialogue doesn't save preferences ["Ask me before opening..."]
hrm, i might've been a bit hasty there...since bug 70017 [a similar issue] is
now wfm.

alas, both bug 70017 and bug 84711 are tricky for me to test since audio doesn't
work on either my winnt or linux box. gah.
alright, ignore my last two comments!

i tested using the samples given in bug 70017 and 84711 on linux [mozilla debug
from 6/14] and winNT [mozilla 2001.06.18.09-talkback-sea], and unchecking the
"Ask me before..." checkbox is adhered to.

it worked...mostly on mac [mozilla 2001.06.18.08], except that the setting
"didn't take" until i restarted mozilla. i'll file a seperate bug for that,
however, and mark this as fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: mozilla only
vrfy'ing as fixed... i filed bug 86523 to cover the mac issue i mentioned above.
Status: RESOLVED → VERIFIED
I am sorry to report that this have regressed. The "Downloading..." dialog was
recently redesigned and it seems that this redesign broke the "always ask me"
again. It seems that now we have two copies of "always ask me". One can be
observed in the "Edit type" dialog, it is remembered correctly; the other
appears in the "Downloading" dialog and is always on, no matter what I do. Since
the one that is actually used appears to be the second one, I am now always
asked, no mattaer what.

Build Id 2001070916 (from mozilla.org RH7 RPMs) on RedHat Linux 7.1
Status: VERIFIED → REOPENED
Keywords: mozilla0.9.3, regression
Resolution: FIXED → ---
Whiteboard: mozilla only
aleksey, could you be running into bug 88330 instead? re-open this if not...
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I think it's related to 88330, but different. In bug 88340 reported says
 
> 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].
 
My problem is that it *does* appear and I do not seem to be able to get rid of that.
 
http://bugzilla.mozilla.org/show_bug.cgi?id=88330

Here is a detailed log of what's ahppening to me (100% reproducible):

1) Edit -> Preferences -> Navigator -> Helper Apps -> application/postscript -> Edit
2) It shows (correctly) that "Ask me ..." is disabled and that I want to use
/usr/X11R6/bin/gv
3) Close all prefs windows (via Cancel)
4) Click on a ps file
5) A "Downloading ..." window appears giving me a choice between gv and "save to
disk" (with gv correctly selected default) and with "always ask" *checked*.
6) (optional) If I press "advanced..." I get "Edit Type" window where "Ask
me..." is still unchecked.
7) Uncheck "Always ask" and press OK.
8) Go back to step 4 and repeat. "Downloading..." window keeps appearing with
"always
ask" *checked* no matter what.

Expected: 
a) When "Ask me" is unchecked, the downloading option dialog should not appear.
b) If "Ask me" is checked, the dowloading dialog should appear, but if I uncheck
"Always ask" in downloading option dialog, it should also uncheck "ask me" and
not appear again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
P.S. This is a regression - this seems to work correctly with 0.9.2, this
problem only started happening when the download option was redesigned (with the
button that recalls "Edit Type" menu now called "Advanced...").
*** Bug 85996 has been marked as a duplicate of this bug. ***
*** Bug 86859 has been marked as a duplicate of this bug. ***
*** Bug 93173 has been marked as a duplicate of this bug. ***
seems that the option in mimeTypes.rdf about NC:alwaysAsk="false" isn't even
written  when i uncheck the "Ask before..." checkbox for a new helper app in
helper app prefs.

However: it doesn't even seem like it would matter, because it isn't honored for
applications it is set for either. Or am i misinterpreting what that setting
should do?
nominating...
Keywords: mozilla0.9.4, nsbranch
I am running mozilla 0.9.3 under RH 7.1.

I've tried to add two helper applications.
One for pdf files to be run by xpdf works properly.
The other for mws files (Maple worksheets) insists on asking me if I want to
open the file with xmaple, and I can't convince it not to.  I've tried by
unchecking the box, but it always comes back the same way.  I've also tried
through preferences.  I've looked at the file mimeTypes.rdf, and I can't make
head or tail of it, but it looks a mess.  Here it is for what is worth

<?xml version="1.0"?>
<RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#"
         xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <RDF:Description about="urn:mimetype:text/html"
                   NC:value="text/html"
                   NC:description="Hypertext Document"
                   NC:editable="false">
    <NC:fileExtensions>htm</NC:fileExtensions>
    <NC:fileExtensions>html</NC:fileExtensions>
    <NC:handlerProp resource="urn:mimetype:handler:text/html"/>
  </RDF:Description>
  <RDF:Description about="urn:mimetype:handler:application/pdf"
                   NC:alwaysAsk="false">
    <NC:externalApplication
resource="urn:mimetype:externalApplication:application/pdf"/>
  </RDF:Description>
  <RDF:Description about="urn:mimetype:externalApplication:application/pdf"
                   NC:path="/usr/bin/xpdf"
                   NC:prettyName="xpdf" />
  <RDF:Description about="urn:mimetype:externalApplication:application/maple-v-r4"
                   NC:path="/usr/local/bin/xmaple"
<RDF:Description about="urn:mimetype:handler:text/html"
                   NC:saveToDisk="false"
                   NC:handleInternal="true">
    <RDF:type resource="http://home.netscape.com/NC-rdf#handler"/>
    <NC:externalApplicationProp resource="rdf:#$lFfZ8"/>
  </RDF:Description>
  <RDF:Seq about="urn:mimetypes:root">
    <RDF:li resource="urn:mimetype:text/html"/>
    <RDF:li resource="urn:mimetype:application/pdf"/>
    <RDF:li resource="urn:mimetype:application/maple-v-r4"/>
  </RDF:Seq>                   NC:fileExtensions="PDF">
    <NC:handlerProp resource="urn:mimetype:handler:application/pdf"/>
  </RDF:Description>
  <RDF:Description about="urn:mimetypes">
    <NC:MIME-types resource="urn:mimetypes:root"/>
  </RDF:Description>
  <RDF:Description about="urn:mimetype:application/maple-v-r4"
                   NC:value="application/maple-v-r4"
                   NC:description="Maple 7 worksheet"
                   NC:editable="true">
    <NC:fileExtensions>MWS</NC:fileExtensions>
    <NC:fileExtensions></NC:fileExtensions>
    <NC:handlerProp resource="urn:mimetype:handler:application/maple-v-r4"/>
  </RDF:Description>
</RDF:RDF>
  <RDF:Description about="rdf:#$lFfZ8">
    <RDF:type resource="http://home.netscape.com/NC-rdf#externalApplication"/>
  </RDF:Description>
  <RDF:Description about="urn:mimetype:handler:application/maple-v-r4"
                   NC:alwaysAsk="false">
    <NC:externalApplication
resource="urn:mimetype:externalApplication:application/maple-v-r4"/>
  </RDF:Description>
  <RDF:Description about="urn:mimetype:application/pdf"
                   NC:value="application/pdf"
                   NC:description="Portable document format"
                   NC:editable="true"
Blocks: 99230
not an Emojo stopper. nsBranch-. triaging.
Keywords: nsbranch → nsbranch-
Target Milestone: --- → mozilla0.9.6
No longer blocks: 99230
Keywords: nsCatFood
spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)
Component: XP Apps: GUI Features → File Handling
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
Blocks: 104166
Blocks: 107067
Keywords: nsbranch-
the "ask me before opening" preference is only saved for the first mime type I
am asked to choose for.
I want to open without asking mp3 and mpeg files (we are presently working on a
project where mozilla browsers will be used to present multimedia content on
computers without mouse in public places, so this functionnality is really
important to us)
When I unchecked the "ask me before" for mp3 files, then for mpeg files, the mp3
files open OK (without asking), not for the mpeg files (it always ask, even if
unchecked).
After pressing "reset" in the Edit->Preferences->Navigator->Helper
Applications->reset
If I first uncheck the "ask me" for mpeg file then for mp3, it works for mpeg,
not for mp3.
moving to 0.9.9
Target Milestone: mozilla0.9.6 → mozilla0.9.9
*** Bug 103619 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1+
I 've noticed the preference is kept for only one MIMEtype in the file
prefs.js  
 for example : user_pref("browser.helperApps.neverAsk.openFile",
"audio%2Fx-pn-realaudio");

if you try to save the neverAsk preference for another MIMEtype, it don't work.

Normally, i've seen the browser uses a comma separated list of the MIMEtypes.
But this list is never created correctly, as I 've seen.
The checkin I just made for bug 113908 might help a lot of the problems people
ar eseeing here on Unix (and on Unix only)
Keywords: mozilla0.9.4
Keywords: nsenterprise
No longer blocks: 107067
Using a windows build from yesterday (2002021803), we are properly storing
multiple content types to the "don't ask me" pref.

i.e.

user_pref("browser.helperApps.neverAsk.openFile",
"audio%2Fx-pn-realaudio%2C%20application%2Fx-zip-compressed");

Boris says he recently checked something in that removed some issues for linux. 

And 88330 covers the disconnects between the checkbox in the helper app dialog
and the Edit / Preferences / Helper apps dialog.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
vrfy'd fixed using 2002.02.21.0x comm bits on linux rh7.2, mac 10.1.2 and win2k.

basic scenario tested:

1. added a mimetype [user-defined] in the helper apps prefs panel.
2. clicked on a link to that'd bring up the helper app dialog and suggest
opening the file with app defined in step (1).
3. deselected the "always ask before..." checkbox, then click OK. results: app
launched [expected].
4. repeated step (2) by clicking on link, and the app launched again without
prompting by the helper app dlg [again, expected].
5. sanity check: quit, restarted, repeated step (4). results: as expected, the
app launched without prompting.
Status: RESOLVED → VERIFIED
I've been experiencing this bug for the last several weeks. I can reproduce with
trunk build 2003052708 with a new profile on Windows 98 by opening MPEG files.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
QA Contact: sairuh → petersen
Details, please?  Like exact steps to reproduce and exact text of the dialog
that you see?
Reproducable: Always

Steps to Reproduce:
1. Go to http://itsaio.chem.uva.nl/movies/bored_at_work/bored_at_work.mpg
2. Uncheck the box "Always show this dialog before handling files of this type"
3. Click OK
4. Go to http://itsaio.chem.uva.nl/movies/bored_at_work/bored_at_work.mpg again

Expected Results: The dialog is *not* shown again when the MPEG file is opened again

Actual Results: The dialog *is* shown again when the MPEG file is opened again

Title of the dialog: Opening bored_at_work.mpg

Exact text of dialog:

The file "bored_at_work.mpg" is of type video/mpg (MPEG Video), and
Mozilla does not know how to handle this file type. This file is located at:
http://itsaio.chem.uva.nl/movies/bored_at_work/

What should Mozilla do with this file?
(o) Open it with the default application (DBC)
( ) Open it with [                                              ] [Choose...]
( ) Save it to disk

[v] Always show this dialog before handling files of this type
-----------------------------------------------------------------------------
                                                       [   OK   ] [ Cancel  ]
URL: http://itsaio.chem.uva.nl/movies/bore...
Using those precise steps I am _not_ able to reproduce this bug on Linux build
2003-05-27-11.  So either this is a Windows-only issue, or this is a problem
with the particular profile you have.  Could you try creating a new profile
using the profile manager and seeing whether that profile also has this problem?
The problem also occurs with a new profile with absolutely no changes to the
preferences. I'll try to get others to comment on how to reproduce it. I asked
in the MozillaZine forums, and at least one other person has noticed this
problem recently, so it can't be too hard to reproduce!
I'm somewhat disgusted to see that this bug has been around for like 3 years and
no one has bothered to fix it.  I've tried Mozilla 1.2.1 and 1.3.  I'm using
linux.  If I delete the .mozilla directory and start from scratch, I can
reproduce this bug 100% of the time by clicking on a link to a PDF file.  I tell
it to run acrobat and uncheck the "Ask me" box.  It insists on always asking me
again and always defaulting to "Save File as.."     
Nice of you to be disgusted.  This WAS fixed.  People are saying it's broken
again.  I can't reproduce the brokenness.  If you can, feel free to offer up
some useful information that would enable me to fix it.

A good start would be if someone seeing the problem would attach their
mimeTypes.rdf and prefs.js files to this bug, for example.
Updating summary to make this bug easier to find.
Summary: download options dialogue doesn't save preferences ["Ask me before opening..."] → downloading/opening options dialog doesn't save preferences ["Always show this dialog before handling files of this type"]
I am experiencing this bug on Linux.  Here is my prefs.js file.  Be advised
that I get this bug even if I move my ~/.mozilla directory and start from
scratch.  I have attached my mimeTypes.rdf file also.
Here is the mimeTypes.rdf file.
Boris,

Are there any other files that could effect the behavior of this bug?   I moved
my ~/.mime.types and my ~/.mailcap files.  It appears that these files contain
MIME application info.  Are there any other files that could affect this?   I
see the bug on a Redhat 7.2 machine, but on my 7.3 machine (running as different
user also) I do not see the bug.  In both cases, I deleted the ~/.mozilla
directory and started from scratch.

Also, I have noticed that I only experience this bug when clicking on files from
the browser.  If I click an attachment from my email, it runs acrobat without
prompting me.  Is the code different for mail vs. the browser? 
Boris,

I have some new information.  The bug does not seem to depend on which machine I
use.  It depends on which website I download a PDF file from.  Some websites
work okay and it does not prompt me.  On other websites it always prompts me. 
The mimetype is the same in both cases because I only have one mimetype that
runs acroread.  Unfortunately I cannot give you the page source for the webpage
that does not work because it is a company internal page.
Paul, is the site that does not work sending a "Content-Disposition:attachment"
header?  You can test by running 'wget -s -O somefile
http://whatever.your.url.is' and then looking at the headers at the top of
"somefile"...
Yes, I believe it is.  I ran the wget command you gave (after figuring out how
to make wget use a web proxy).  Here is the header from "somefile"

HTTP/1.0 200 OK
Date: Thu, 12 Jun 2003 18:27:51 GMT
Content-Type: application/pdf
Set-Cookie: JSESSIONID=@6ae5b3:f5bd460aab;path=/
Server: SilverStream Server/10.0
Content-Disposition: attachment; filename="LM93MTD_06_A.PDF"
Via: 1.1 www-proxy (NetCache NetApp/5.4R2D1)

%PDF-1.2
%ту╧╙
2 0 obj
<<
/Length 10620
/Filter /FlateDecode
>>
stream

[binary data follows which I left out]

I should also mention that clicking this link from Mozilla spawns a new empty
mozilla window before showing the download dialog box.

I hope this info is enough to help you figure out the problem.
Paul, you're seeing bug 193698, not whatever Steve is seeing in comment 41 (I
checked his URL and it does not send such a header as far as I can tell).

Steve, any more information you can provide would be much appreciated.
For example in the page http://remix.kwed.org/ I would like to be able to hear
the tunes. Now for everytime I try to listen to a tune a popup informs me of my
choices, and even thought I uncheck the box "always show this dialog before
handling files of this type".

Im trying to open the sid files with my winamp. :-)
hm, that may be due to the bug that the mimetype mozilla shows in the dialog is
not what the server sent

That server sends headers like:

Content-Disposition: Thomas Detert - Supernova (the slow tune).mp3

Which is equivalent, per spec, to

Content-Disposition: attachment.

People, please check the HTTP headers being sent by the site you are having the
problem with before commenting; anything involving Content-Disposition headers
and Mozilla's handling of them is NOT this bug.
I've found a workable fix for it, or at least a possible source.  When i
received content with the mime-type audio/mpegurl i observed this bug - or at
least effects much like it - in moz 1.3, and 1.4rc[1|2].

My fix was altering the MIME-type from audio/mpegurl to audio/x-mpegurl and that
fixed it completely.  No more requests.  Hope this helps.
Chris, could you attach your mimeTypes.rdf and prefs.js files here or email them
to me?
The fix as suggested by Chris Rose (#57) really does work. Using mozilla 1.4 on
W2K (build 2003052908) I tried it on the wav-files at
http://www.geocities.com/Hollywood/2745/ using Winamp as the helper app.
Changing the mime type audio/wav to audio/x-wav made the popups disappear.
Changing it to anything else (e.g., audio/y-wav) just created a new copy of
audio/wav, with the same popup problem. As expected, I suppose.

Apparently, the "x-" addition makes it more tolerant??

This will be easy to reproduce I suppose. If any pref-files are needed, I can
send them on request. 
Please attach your prefs.js and mimeTypes.rdf to this bug.

I may not get to this before I lose net access, though... 
Colin, Chris: You are most likely seeing bug 184971 which was recently fixed
*** Bug 209840 has been marked as a duplicate of this bug. ***
*** Bug 215732 has been marked as a duplicate of this bug. ***
wfm. last remaining issue was probably bug 184971 as well as
content-disposition:attachment, and those are fixed.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: