Please note, this is a STATIC archive of website from 03 Nov 2016, does not collect or store any user information, there is no "phishing" involved.

Helper Apps (and a bit of Save As)

Warning: The content of this article may be out of date. It was last updated in 2002.

Bird's Eye View


Flow of control

  1. URILoader tries to find a content listener for the MIME type in question.
  2. When this fails, URILoader asks an nsIExternalHelperAppService to handle the load.
  3. The nsExternalHelperAppService looks up the nsIMIMEInfo for the load and creates an nsIHelperAppLauncher to manage the load.
  4. The nsExternalAppHandler (which implements nsIHelperAppLauncher) uses the nsIMIMEInfo and an nsIHelperAppLauncherDialog to decide what to do with the data.
  5. The nsExternalAppHandler does whatever it decided to do.

nsIMIMEInfo lookup

  1. Look in built-in list which the user cannot override (types we handle internally).
  2. Look in user preferences.
  3. Ask the OS:
    • Registry on Windows.
    • Internet Config on the Mac.
    • mailcap/mime.types on Linux.
  4. Look in second built-in list, which the user can override.

nsExternalAppHandler details

  • Implements nsIStreamListener.
  • Gets notifications from Necko as the data comes in.
  • Four primary tasks:
    1. Sets up temporary file and instantiate the nsIHelperAppLauncherDialog in OnStartRequest.
    2. Puts the data in the file as OnDataAvailable notifications come in.
    3. Knows how to launch a helper application on the data based on the nsIMIMEInfo.
    4. Knows how to save the data to disk at a given location if the user decides to do so.


  1. Creates a temporary file with a salted name to hold the data.
  2. Decides on a suggested filename for the data in case it will be saved.
  3. Decides whether the data should be content-decoded (based on some not-so-great heuristics).
  4. Decides whether the user should be prompted (based on a preference).
  5. Calls Show() on the nsIHelperAppLauncherDialog, which asynchronously puts up the helper app dialog.


  • Here we just copy the newly arrived data over into our temporary file.
  • If any read or write errors occur, abort the whole process:
    1. Cancel the channel.
    2. Pull down the helper app dialog (if any).
    3. Remove the temp file.


Set a flag that we're done, then do whatever the user wants if the user has decided (save to disk and open in helper are the current options the user has).

Helper App dialog

This is our implementation of nsIHelperAppLauncherDialog


It calls back to the nsExternalAppHandler to let it know what the user picked

Saving to disk

If a user decides to "save to disk", we just move/copy the temporary file over to the chosen location once the download completes. If an error occurs while we do this we delete the temp file and put up an error dialog.

Launching a helper application

This is delegated to the nsPIExternalAppLauncher (also implemented by the nsExternalHelperAppHandler):

  • Windows: launch either directly via nsIProcess or via the ::ShellExecute() method depending on where the MIMEInfo came from. Last-ditch check for executable files here.
  • Mac: use the LaunchWithDoc() method on nsILocalFileMac.
  • Unix: launch directly via nsIProcess.

Security considerations

Multiple checks for whether a file is executable (on Windows) to keep from launching such files via ::ShellExecute(). Checks happen in OnStartRequest, in the helper app dialog, and as a last ditch in the launching code.

Limitations of nsIMIMEInfo

  • No way to say "do whatever the OS default is."
  • No support for command-line arguments.
  • No support for multiple commands connected by pipes (mostly useful on Unix).

Ongoing work

  • Support synchronous dialogs, not just asynchronous ones (fixes many issues related to pre-downloading, content-decoding, etc).
  • Reworking the nsIMIMEService API to improve the quality of the MIMEInfo we get.
  • Reworking the helper app dialog to save user choices better.
  • GNOME integration for Unix.

Future work

  • Fix the deficiencies in nsIMIMEInfo.
  • Better support for mailcap syntax.
  • Possible KDE integration.
  • Possibly reflecting the OS settings in our helper app preferences (readonly? writable?).
  • Have a way for users to override things in the "not overridable" built-in list.

Original Document Information

  • Author(s): Boris Zbarsky
  • Last Updated Date: September 12, 2002
  • Copyright Information: Portions of this content are © 1998–2007 by individual contributors; content available under a Creative Commons license | Details.

Document Tags and Contributors

 Contributors to this page: teoli, kohei.yoshino
 Last updated by: kohei.yoshino,