Pulling out the remaining UI work from the parent bug: Bug #38374. This dialog is similar (if not reusing) the unknown content handler dialog. We want to show them a dialog saying something like: Open using *application* Save to disk and never ask me or always ask me again. I need to sit down with Bill tomorrow to work out how I'm going to get the right back end objects over to his dialog. It's going to be tricky because I can't block the uriloader while we bring up this dialog. I have a few ideas though.

Copying feature exception status from the parent bug to this one.

OK, this might be a dup, but it's at least related to bug #28584. mscott, thanks for filing these!

I see similarities too...mscott, would this be using the pickapp button?

Adding myself to cc: list.

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

Update completion date. Sigh.

Should the URIloader be blocked while having that dialog? I twould be really convienient if the download of the file could start anyway while the dialog is presented, saving some download time afterwards.

The uriloader isn't blocked and the download does occur in the "background." If you choose save-to-disk, it will simply mv the file to where you asked to save to. That's the plan, at least.

All my code is checked in. What remains is to tweak the uriloader code that invokes the dialog. Here is the code that I used for testing (this only works in conjunction with other patches that mscott provided me). When this code is added then the dialog will appear. Index: nsExternalHelperAppService.cpp =================================================================== RCS file: /cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v retrieving revision 1.16 diff -u -r1.16 nsExternalHelperAppService.cpp --- nsExternalHelperAppService.cpp 2000/07/10 21:21:09 1.16 +++ nsExternalHelperAppService.cpp 2000/07/11 23:20:30 @@ -42,6 +42,7 @@ #include "nsIMIMEInfo.h" #include "nsCExternalHandlerService.h" // contains progids for the helper app service +#include "nsIHelperAppLauncherDialog.h" static NS_DEFINE_CID(kRDFServiceCID, NS_RDFSERVICE_CID); static NS_DEFINE_CID(kRDFXMLDataSourceCID, NS_RDFXMLDATASOURCE_CID); @@ -469,9 +470,10 @@ mReceivedDispostionInfo = PR_FALSE; // invoke the dialog!!!!! use mWindowContext as the window context paramete r for the dialog service - - - + nsCOMPtr<nsIHelperAppLauncherDialog> dlgService( do_GetService( NS_IHELPERA PPLAUNCHERDLG_PROGID ) ); + if ( dlgService ) { + rv = dlgService->Show( this, mWindowContext ); + } } else mReceivedDispostionInfo = PR_TRUE; // no need to wait for a response from t he user

awesome! I'll apply your patch and try it out. If it works do you want me to check it in? (I don't have any diffs in my tree any patch I gave you has already been checked in)

Yes, please test it out, especially on Mac or Linux (I could only test it there because I didn't have your other changes). I'll work on updating my Mac and Linux builds now, but it will take a little while.

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

I'd like to reiterate that without this dialog we're downloading and executing files without the user's permission. This is a major security hole, and since it's publicly known (it was reported from outside Netscape in 40857), we can't ship until this is fixed.

I've turned this dialog on by default. However, there are still a couple small issues to be ironed out between Bill and I. Let's leave this open for a day or so to see if we can get everything cleaned up under this bug.

I'm closing this bug out since the dialog is up and running, more or less. Any problems should be addressed with new bugs.

verified with 071708 mozilla build on NT4

This is failing for some strange reason on Win98 for me (but only in release builds). There are similar reports from mscott (not sure what platform). Something is amiss, but I'm not sure what to do about it.