You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Improve Helper Application Management

Detailed Description

This set of features relate to the "Helper Applications" preference panel.

The "features" listed under this line item can be categorized as follows:

  • Helper Applications Pref panel feature(s)

    Specifically, "reflecting" OS-defined helper applications.

  • Profile Manager feature(s)

    Specifically, "importing" settings from 4.x.

  • Making it work the way it is supposed to

    Specifically, "reflecting" registered helper apps and user decisions, and "Fix bugs."

Re: Making it work the way it is supposed to

This is bug fixing and not addressed by this plan.

Re: Automatically import settings from 4.x:

The only place this can happen is when migrating a 4.x profile, or, optionally when creating a new profile. It can apply in the latter case because the Communicator settings are actually stored on a per-machine (or per-Windows-user) basis so we could extract that information for every new profile, not just ones explicitly "copied" from a specific Communicator profile.

Regardless, this is a Profile Manager feature and will not be addressed by this plan.

Re: Helper Applications Pref Panel feature(s)

The current implementation of this panel is based on the mimetypes.rdf file, which contains only browser-specific helper application entries. Currently, this information is manipulated as a generic RDF datasource, by code in 3 places:

  • the URILoader
  • the Helper Application prefs panel (and related dialogs)
  • the "download dialog", aka "unknown content dialog" (nsIHelperAppLauncherDialog implementation)

To merge the OS-defined settings, we need to create a new RDF data source that encapsulates the OS settings (requires separate implementation for each platform), and another datasource that merges that new one with current mimeTypes.rdf data.

This feature is the only work addressed by this plan (and the detailed Task and Issues lists, below).

Design

The solution to this problem must provide the additional functionality (display the "inherited" OS mime-type/helper-app settings in the helper app pref panel), and, resolve some of the more irksome problems with the current implementation of this area of Mozilla.

Those issues include:

  1. Too many dependencies on the mimeTypes.rdf implementation

    There are at least 3 sets of code that have hard dependencies on mimeTypes.rdf, and, that duplicate, to some extent, the logic that maintains that data source. At a minimum, we should consolidate that code. It would be nice to go the extra step and consolidate it behind a higher-level interface that hides the RDF implementation detail.

  2. Download dialog dependency on prefs

    Currently, the "Advanced..." button on the download dialog (the one that asks if you want to open the file or save it to disk) opens the same Helper App "edit/new type" dialog as does the Helper App pref panel (via the New/Edit buttons). The problem in general is that this is an awkward dependency. The pref panel is an application-specific UI component while the download dialog is part of the "core" of Mozilla (a peer to the uriloader). This is a real issue for embedding, because this dependency makes it hard to draw a line around the "embeddable" Mozilla which includes the download dialog (at least the default .xul implementation of that interface). We need to move the code that the Advanced... button triggers into a "lower level" component (and separate it via an interface so that embedders can replace it with their own UI).

  3. Discrepancies between the "New Type" and "Edit Type" dialogs

    The "New Type" helper app dialog doesn't let you say "[don't] always ask me" for the new mime type. The Edit Type dialog doesn't let you change the description for the mime type. I think there only needs to be 1 dialog, with an input argument that specifies which mode it is in (and to control things like not changing the mime type when invoked from the download dialog). We should try to resolve these problems when we transition the implementation from the helper app pref panel.

If we examine the 3 "clients" of the helper application information in Mozilla (the pref panel, the uriloader, and the download dialog), the requirements are:

  1. to get helper app info for a given mime type (or file extension)
  2. to enumerate the list of mime types
  3. to add "helper app information" for new mime types
  4. to modify the info stored for a given mime type
  5. to have the OS-defined mappings from mime-type to helper app to show up automagically
  6. to have user-defined (via prefs) helper app settings to overlay the OS-defined settings
  7. to open a dialog to let the user modify the helper app settings for a given mime type.

The helper app pref panel implementation is driven by an RDF data source. Currently, that data source is a simple nsRDFXMLDataSource wrapper around the mimeTypes.rdf file.

If we replace that data source with an nsIRDFCompositeDataSource then the prefs panel should, theoretically, be able to still work with no change (since that interface is-a nsIRDFDataSource).

That composite data source will be composed of:

  • The existing mimeTypes.rdf data source
  • A new component implementing the nsIRDFDataSource interface by encapsulating the information in the native OS helper app settings.

Given that, all the requirements would appear to be met relatively easily. All the requests that currently go to the sinle mimeTypes.rdf data source are automagically extended to fall back to the secondary native helper app data source.

To better hide the defails of this implementation, most access to the mime types and associated helper app information will be via a higher-level interface that deals with nsIMIMEInfo objects. That interface will translate requests to the necessary RDF. That will, hopefully, move all the RDF-specific code that currently is spread between the 3 clients.

That higher-level interface is essentially nsIMIMEService, with the addition of a new method to add new entries and update entries: 

    /* Adds or updates the MIME info associated with a given 
     * mime type.
     *
     * @param  A MIME info object that provides the new or
     *         updated information.
     */
     void UpdateMIMEInfo( in nsIMIMEInfo aMIMEInfo );

This method would be implemented in such a way that only new/modified information would be added to the mimeTypes.rdf data source.

For example, let's say the user went to the new helper app pref panel and editted the entry for audio/x-pn-realaudio to uncheck the "always ask me before opening" checkbox. We would not want to store the application in mimeTypes.rdf, because that would result in the wrong application being used if the user upgraded to a new version of RealPlayer (or switched to using Windows Media Player). RDF makes this relatively painless to do.

Tasks

  1. Implement new RDF data source that reflects OS settings for helper applications. Requires mostly platform-specific code. The plan is to provide this capability on Win32 and Mac platforms only. 15 days

    Broken down into subtasks:

    1. Define new RDF datasource interface and implement shared (platform-independent) portion, along with requisite build-system magic to build alternate implementations for each platform. 5 days
    2. Do Win32 implementation of this interface. 5 days
    3. Do Mac implementation of this interface. 5 days
  2. Implement new RDF data source that will "merge" the OS-settings datasource with the existing mimeTypes.rdf data source. More precisely, modify code that uses the existing "simple" RDF datasource so that it uses a "composite" datasource consisting of the new datasource described above, and, the existing mimeTypes.rdf based datasource. 9 days

    Broken down into subtasks:

    1. Modify .xul and .js code for pref panel to use the composite datasource. 3 days
    2. Modify C++ code in uriloader and uriloader\exthandler to use composite data source. 3 days
    3. Modify .js code in nsHelperAppDialog to use new composite datasource 3 days

Issues

  • What about plug-ins? Communicator included plug-ins in the helper app list and by rights Mozilla should do likewise (there are bugs on that, I believe). There is a separate line item for Navigator to show plugins in the helper app pref panel. That support should be implemented as an RDF datasource and then "composited" with the two described here.

    The additional work here to deal with that additional datasource:

    1. Add the plugins datasource to the composite datasource. 1 day
    2. UI changes to handle plugins (e.g., the user cannot change the mimetypes for plugins, or indicate that they should be "asked"). 2 days
  • The Mac implementation of the "OS helper app" data source will very likely require some expertise on that platform. There is already a wrapper of sorts for the Mac Internet Config settings and if the data source can be implemented on top of that, then the specific Mac expertise required will be much reduced.
  • Are there usability issues related to showing the user too many file types? On Windows, under Communicator, I see 200+ file types listed.
  • What do we use for the "OS settings" on Linux? This plan does not include showing such helper applications on platforms other than Win32 and Mac.

Links

Helper app meta bug dependency tree