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

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Blake Ross]

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.

Comment 1

[sairuh (rarely reading bugmail)]

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].

Comment 2

[sairuh (rarely reading bugmail)]

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.

Comment 3

[sairuh (rarely reading bugmail)]

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.

Comment 4

[R.K.Aa.]

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)

Comment 5

[sairuh (rarely reading bugmail)]

[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.

Comment 6

[sairuh (rarely reading bugmail)]

rkaa, d'you know the bug offhand for save/open not working? thx!

Comment 7

[R.K.Aa.]

not filed yet, AFAIK.

Comment 8

[sairuh (rarely reading bugmail)]

filed bug 97658 for the save and open issue.

Comment 9

[Dave]

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).

Comment 10

[Dave]

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...

Comment 11

[sairuh (rarely reading bugmail)]

nominating.

blake/mscott, i understand that you might be swamped ;), but any ideas as to why
this might be happening? thx!

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

Dupe of bug 48948.

*** This bug has been marked as a duplicate of 48948 ***

Comment 13

[sairuh (rarely reading bugmail)]

v

Comment 14

[sairuh (rarely reading bugmail)]

hrm, on second thought: since the end result is different from bug 48948
[getting the saving dialog], i'm reopening this.

Comment 15

[R.K.Aa.]

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.

Comment 16

[grega]

marking PDT to keep on the radar.  Are users totally horked or can they work
around these issues?  (I know it's ugly)  Thanks!

Comment 17

[sairuh (rarely reading bugmail)]

*** Bug 96425 has been marked as a duplicate of this bug. ***

Comment 18

[Scott MacGregor]

i don't believe this is a stop ship bug. 

Comment 19

[sairuh (rarely reading bugmail)]

okay --need to relnote. jatin, what's your latest relnote bug?

Comment 20

[sairuh (rarely reading bugmail)]

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. :(]

Comment 21

[R.K.Aa.]

*** Bug 101107 has been marked as a duplicate of this bug. ***

Comment 22

[Niels Aufbau]

Sairuh, I don't understand how this is different from bug 48948.  Can you
explain again?

Comment 23

[sairuh (rarely reading bugmail)]

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.

Comment 24

[Hong Kwon]

marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Comment 25

[Gervase Markham [:gerv]]

Adding useless-ui keyword. If the "always ask me" checkbox does nothing, it
should be removed from the dialog.

Gerv

Comment 26

[Ashley Bischoff (blog at handcoding.com)]

*** Bug 104458 has been marked as a duplicate of this bug. ***

Comment 27

[Jaime Rodriguez, Jr.]

Removing [PDT] grafitti because this was minused by component team.

Comment 28

[Christopher Aillon (sabbatical, not receiving bugmail)]

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?

Comment 29

[Boris Zbarsky [:bzbarsky]]

see bug 111035

Comment 30

[Boris Zbarsky [:bzbarsky]]

This was a duplicate of bug 111035, in my opinion

Comment 31

[Boris Zbarsky [:bzbarsky]]

*** Bug 117784 has been marked as a duplicate of this bug. ***

Comment 32

[sairuh (rarely reading bugmail)]

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].

Comment 33

[Peter Trudelle]

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?)

Comment 34

[Bill Law]

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.

Comment 35

[Peter Trudelle]

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.

Comment 36

[sairuh (rarely reading bugmail)]

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. :) 

Comment 37

[Jaime Rodriguez, Jr.]

nominating ...

Comment 38

[Peter Trudelle]

nsbeta1+ per nav triage team

Comment 39

[Bill Law]

Working on this stuff next.

Comment 40

[Boris Zbarsky [:bzbarsky]]

*** Bug 128949 has been marked as a duplicate of this bug. ***

Comment 41

[Peter Trudelle]

ADT3 per ADT triage team.

Comment 42

[Peter Trudelle]

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.

Comment 43

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 44

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 45

[gabriel]

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 ?

Comment 46

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 47

[gabriel]

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.

Comment 48

[Boris Zbarsky [:bzbarsky]]

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.

Comment 49

[R.K.Aa.]

*** Bug 141698 has been marked as a duplicate of this bug. ***

Comment 50

[R.K.Aa.]

*** Bug 146948 has been marked as a duplicate of this bug. ***

Comment 51

[gabriel]

Under Linux you could get unknown mime types from /etc/mime.types. Is that of
any help ?

Comment 52

[Boris Zbarsky [:bzbarsky]]

If it's in there it's not unknown.  We already read that file.

Comment 53

[Boris Zbarsky [:bzbarsky]]

*** Bug 152118 has been marked as a duplicate of this bug. ***

Comment 54

[sairuh (rarely reading bugmail)]

would be good to fix for buffy...

Comment 55

[Akkana Peck]

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.

Comment 56

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 57

[Boris Zbarsky [:bzbarsky]]

This should be fixed now that bug 86640 has landed.  Please retest.

Comment 58

[sairuh (rarely reading bugmail)]

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).

Comment 59

[Chris Petersen]

Verified on the Win32 2003-01-23-04 and OS X 2003-01-23-03 trunk build.

Comment 60

[Hakon]

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...?

Comment 61

[Boris Zbarsky [:bzbarsky]]

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.