Closed Bug 93173 Opened 23 years ago Closed 22 years ago

Helper app decision isn't remembered [using Open for non-OS-defined types]

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: bugzilla, Assigned: law)

References

Details

(4 keywords, Whiteboard: [adt2]) 

Build ID: 2001080103

Steps to Reproduce:

(1) Click on a file for which you don't have a helper app set up (I used one of
the links to builds at mozilla.org)
(2) Leave the default radiobutton checked (Open with...)
(3) Uncheck "Always ask me..."
(4) Click the link again

You get the dialog again.
okay, i'm not sure if this is the same bug here, but this is what i see [using
2001.08.29.11-comm bits on winNT]:

1. i went to http://mozilla.org and clicked on the Mac OS X download link [for
which there's no OS-defined type on my box].
2. the helper dialog had "save as" selected. i selected "open with" and then
chose Winzip32.exe to handle it.
3. i deselected the "always ask..." checkbox.
4. click OK, and Winzip launches and opens the file.
5. i close the download progress dialog ["saving file" dialog], then click on
the Mac OS X link again.

result: i get the native file picker dialog asking me where to save the file
["enter name of file to save to..." dialog].

blake, what are you seeing now with a more recent build?

i wonder if the behavior differs btwn mozilla and commercial bits [i'll go check
that theory now].
just tried with the 2001.08.29.11-mozilla talkback build, and i get the same
results i did with the 2001.08.29.11 commercial build.
i tested on linux 2001.08.29.08-comm and i get the same results i had seen on
2001-08-29 20:03.

will test mac once the classic env starts up...

i've modified the summary with the current behavior. however: blake, would you
let  us know if you're seeing the originally reported behavior still?

rkaa, dave, mscott: d'you experience this at all?

bumping up the sev here. this is a regression of one of baseline functionality
--at least on my machines.
Severity: normal → critical
Keywords: mozilla0.9.4, regression
OS: Windows 2000 → All
Hardware: PC → All
Summary: Helper app decision isn't remembered → Helper app decision isn't remembered [using Open for non-OS-defined types]
there's some new horkage: Save As, Save, Open etc all fail to spawn a dialog.
No dialog when i click links to files either - them are gonners.
So at least on linux this is a impossibe to test right now (official trunk
build, ID 2001-083008)
[sidenote about linux testing: the app i chose to open was rather arbitrary:
/usr/bin/gimp]

testing on mac OS 9.1 [2001.08.29.08-comm] gave similar [but not completely the
same] results:
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 had "save as" selected. i selected "open with" and then
chose StuffIt Expander to handle it.
3. i deselected the "always ask..." checkbox.
4. click OK, and the app launches and opens the file.
5. i close the download progress dialog ["saving file" dialog], then click on
the .bz2 link again.

results: i get the file picker dialog asking me where to save the file.

6. i cancel the file picker.
7. go to Helper App prefs and click on Reset. dismiss prefs.
8. click .bz2 link again.

results that differ from linux and win32: the helper app dialog somehow still
displays the path to the application i had chosen in step 2. in linux and win32,
as expected, "open" had "<no application specified>" displayed. either way,
"save to disk" is selected. however, quitting and restarting the app clears this
up on mac.

anyway, cc'ing rpotts --i wonder if his fix for bug 96418 might've caused the
diff in behavior btwn what blake and i see.
rkaa, d'you know the bug offhand for save/open not working? thx!
not filed yet, AFAIK.
filed bug 97658 for the save and open issue.
This worked but didn't work for me... :-) 2001082910/Linux (no gcc295 builds today).

I went to cdnow and clicked on one of the realaudio links and got the dialog so
I hit "Advanced..." and set up the helper app then I un-checked the "always
ask..." box and I didn't get the dialog anymore.
I then restarted the browser and the helper app was still there and I didn't get
the dialog.

_But_ I then removed the helper app and clicked on the link again and got a
"save as" dialog with "source=RAM" in the "File name:" text box.

I wasn't able to test with choosing an app to open with and then unchecking the
box because of the above problem. I think, however, that this isn't supposed to
work because a helper app hasn't been configured (though it would probably be
possible to configure one with default values if someone chose to do that).
OK, tried restarting the browser like sairuh did on mac and, voila, the
realaudio helper app I'd configured (and removed) is back and working just fine
and dandy (no dialog).

Encouraged by this success, I went to http://www.mp3.com and clicked on a link
for an mp3 (the links labelled "Download" on the artist pages) and got the
dialog (I'm already "registered" with mp3.com so I didn't have to do that). I
then clicked on "open with" and chose /usr/bin/xmms (this as oposed to clicking
"Advanced..." and configuring the helper app). xmms got run and played the file.

I then proceeded to close xmms and click on the link again. This time I got a
"save as" dialog. I tried restarting the browser again and still got the save as
dialog. I checked my helper apps under prefs and there's nothing for mp3s so I
guess my mp3 helper app is permanently horked now...
nominating.

blake/mscott, i understand that you might be swamped ;), but any ideas as to why
this might be happening? thx!
Keywords: nsbranch, nsenterprise
Dupe of bug 48948.

*** This bug has been marked as a duplicate of 48948 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
hrm, on second thought: since the end result is different from bug 48948
[getting the saving dialog], i'm reopening this.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
not at all sure, but i have a hunch mimeTypes.rdf is storing garbage.
Earlyer, whenever i edited a mimetype, instead of modifying the current entry, i
got a new written to mimeTypes.rdf.

Looking at the attachment in bug 98084 (same problem) and comparing with my own
entry in mimeTypes.rdf, it seems something weird is still going on there.
marking PDT to keep on the radar.  Are users totally horked or can they work
around these issues?  (I know it's ugly)  Thanks!
Whiteboard: PDT
*** Bug 96425 has been marked as a duplicate of this bug. ***
Blocks: 99230
i don't believe this is a stop ship bug.
Keywords: nsbranch → nsbranch-
okay --need to relnote. jatin, what's your latest relnote bug?
Keywords: relnote
tested using 2001.09.20.17-branch comm bits on linux: when i encountered this, i
quit the app and dumped core. :(

found a workaround to avoiding the save as dialog: after quitting, i restarted
and went to the helper apps pref panel. i clicked the Reset button, then
dismissed the prefs dialog. [hm, i didn't get a confirmation dialog after
clicking Reset --i forget if that's expected. :(]
Keywords: crash, mozilla0.9.5
*** Bug 101107 has been marked as a duplicate of this bug. ***
Sairuh, I don't understand how this is different from bug 48948.  Can you
explain again?
Whiteboard: PDT → [PDT]
niels: i think this bug is different from bug 48948 because the end-result
differs.in this bug, i get the saving file picker dialog after deselecting the
"always ask" checkbox. in bug 48948, the helper app dialog still reappears after
deselecting the "always ask..." checkbox.
Component: XP Apps: GUI Features → File Handling
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
Adding useless-ui keyword. If the "always ask me" checkbox does nothing, it
should be removed from the dialog.

Gerv
Keywords: useless-UI
*** Bug 104458 has been marked as a duplicate of this bug. ***
Removing [PDT] grafitti because this was minused by component team.
Whiteboard: [PDT]
Blocks: 107067
Keywords: nsbranch-
Whiteboard: [Aufbau-P3]
Whiteboard: [Aufbau-P3]
Sairuh, I see the same thing for this bug as I do for bug 48948.  The steps to
reproduce in this initial bug report are the same exact as in 48948 and I get
the same results in both bugs... 

Sorry if I'm confused but could you please explain more clearly what you're
seeing and steps to reproduce?
Blocks: 113908
This was a duplicate of bug 111035, in my opinion
Depends on: 86640
*** Bug 117784 has been marked as a duplicate of this bug. ***
nominating yet again. unfortunately, this still seems to be an issue, even
though bug 88287 was fixed. :(

mscott, should this remain on plate?

here are my current observations, using 2002.01.23.0x commercial verif builds on
linux rh7.2, mac 10.1.2 and win2k.

1. went to http://mozilla.org/ and clicked on a download link [for which there
is no OS-defined helper app]. for mac, i clicked on the Windows link; for win2k,
i clicked on the Mac OS X link.
2. in the resulting helper app dlg, selected the "open with an application"
radio button.
3. clicked Chose and selected some app to launch.
4. also deselected the checkbox for "always ask before opening this type of file."
5. clicked OK. results: helper app launches [expected].
6. repeat step 1. results: got the file picker [this bug].
7. exit and restart app.
8. repeat step 1. results: still got the file picker [this bug].
Keywords: helpwanted, nsbeta1
Scott, should we have this bug?  It may not be important for mail/news, but it
is for the browser.  removing excess keywords (should nsenterprise be removed too?)
Keywords: mozilla0.9.4, mozilla0.9.5, useless-UI
I suppose I should have this bug, since I'm doing most of the
uriloader/helper-app stuff of late.

The problem here is that if you don't go to the Advanced... dialog, then we
never create a helper app entry.  We do store the "always ask me" state for the
mime type, though.  But it stays in "save to disk" state, instead of "open using."

It sounds like we could create the helper app entry in this case.  There might
be a problem when the helper app is one specified via the OS.  In that case,
we'd be storing that setting in our prefs and we wouldn't reflect changes the
user subsequently made in their OS settings.
That's a harder problem to solve.  But maybe it's not such a big problem
(meaning users might rarely change the application that handles a given mime
type at the OS level, and they can "fix" the problem by deleting the helper app
entry we generate and start over from scratch).

Thoughts?

I'm targetting this for mozilla0.9.9.  The simple fix is less than a day's work.
Assignee: mscott → law
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9.9
I agree, browser users are extremely unlikely to ever change any MIME type
association of a file at the OS level.  Those that are able to are certainly
able to change it in the browser as well, so it wouild be an obscure, minor
inconvenience.  I'd gladly accept that bug in exchange for getting this one
fixed as easily as possible.
bill and peter, i concur with you. just need to make sure a bug is filed --if it
really crops up after this bug is resolved as you suggested-- for the 'helper
app is one specified via the OS' situation. (ie, for tracking purposes, at
least. :) 


nominating ...
Blocks: 123821
No longer blocks: 107067
Keywords: nsenterprise-
nsbeta1+ per nav triage team
Keywords: nsbeta1 → nsbeta1+
Working on this stuff next.
Target Milestone: mozilla0.9.9 → mozilla1.0
*** Bug 128949 has been marked as a duplicate of this bug. ***
ADT3 per ADT triage team.
Whiteboard: [ADT3]
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.
Target Milestone: mozilla1.0 → mozilla1.0.1
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
Is any progress being made on this ? This is one of the most annoying bugs
remaining in Mozilla for me. If it's a simple fix (as is suggested in comment
34) why are we still waiting ?

Surely you are not considering releasing Mozilla 1.0 with helper apps hopelessly
broken ?

> Is any progress being made on this?

See the patches in bug 86640

> If it's a simple fix (as is suggested in comment 34)

The fix suggested in comment 34 is what's implemented in bug 86640.  It's simple
conceptually, lots of code in practice.

> Surely you are not considering releasing Mozilla 1.0 with helper apps
> hopelessly broken ?

Not only are we considering it, but it's going to happen.  If this bug had
gotten fixed somewhere in the 0.9.9 timeframe it would have been fixed for 1.0. 
As it is, the changes needed for any sort of fix to this are far to risky to
take on the branch.

I don't like this any more than you do, but I didn't have the time back then to
fix it, and neither did Bill.  No one else stepped up.
Can't it at least be patched so that 'open using' gets written to prefs.js ?
That would be enough for me. (Or is that a big change too ?). Failing that, just
not writing 'always save' when I choose not to save would also be a big improvement.

Sorry for the spam.


The second of those two could be doable, without _too_ much code, if someone
does it.  I just don't have the time... :(

You would want to look at
embedding/components/ui/helperAppDlg/nsHelperAppDlg.{xul,js} and make sure that
SetAlwaysAskBeforeHandling() does not get called in certain conditions...  Then
test the hell out of the resulting code.


*** Bug 141698 has been marked as a duplicate of this bug. ***
*** Bug 146948 has been marked as a duplicate of this bug. ***
Under Linux you could get unknown mime types from /etc/mime.types. Is that of
any help ?

If it's in there it's not unknown.  We already read that file.
*** Bug 152118 has been marked as a duplicate of this bug. ***
would be good to fix for buffy...
Keywords: nsbeta1- → nsbeta1
It's pretty poor that the only way to get it handled right is for the user to
edit ~/.mailcap by hand, after showing the user a dialog that implies that we'll
handle it.

The current functionality is that if you uncheck "always ask" (and don't edit
~/.mailcap), then the next time you see that type, you get a "Save as" dialog
with no way to choose a helper app.
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT3] → [adt2]
Blocks: 170086
QA Contact: sairuh → petersen
This should be fixed now that bug 86640 has landed.  Please retest.
hey, this no longer seems to be a problem --at least when using 2003.01.13.08
(comm trunk) on linux rh8.0. marking fixed (due to the landing of bug 86640).
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Verified on the Win32 2003-01-23-04 and OS X 2003-01-23-03 trunk build.
Status: RESOLVED → VERIFIED
It seems as this only works if there is a file extension given.
If there is an image with a proper content-type header but the name is just
"Image1" or so, the association isn't remembered. Reopen...?
Worksforme on Linux.  Note that if we're putting up that dialog for an _image_
it's because the server has explicitly asked us to.  In that case we always
default to "save", since that's what IE does.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.