Status

Feature tracking bug

• bug 380415

Has a design review been completed?

The design has been reviewed incrementally in bug 380415, its dependent bugs, and ongoing discussions in and newsgroups. A single, comprehensive, high-level review has not happened, and is not currently planned (other than this security review).

When do you anticipate the feature landing

We were feature-complete in mid-September. Bug-fixing is ongoing.

Any relevant status comments for the feature can be placed here.

Overview

It is now possible to have URIs with protocol schemes that are not handled internally (e.g. webcal:, mailto:, news:, etc.) handed off to web-based handlers in addition to desktop applications.

Use Cases

• Users who primarily use web mail should be able to click mailto: links and have them do the right thing (open their webmail applications in compose mode) rather than opening a compose window in a mail app that they don't use (e.g. Outlook Express).
• Users who primarily use web calendars should be able to click webcal: links and have them subscribe to the ICS calendars in question.
• (etc.)

Requirements

• Support web-based protocol handlers in the backend (bug 380415)
• Handlers should be selectable/configure from a dialog similar to the unknown content type handler for MIME types.
• Allow web sites to register new content handlers, including prompting user whether or not add requested protocol handlers
• Preferences API should exist for managing configured content handlers
• Be able to inject possible handlers into new and existing profiles

UI Design Documentation

use cases and expected user knowledge (terminology, metaphors, etc)

design mockups (of whatever fidelity is easiest)

ContentHandling:User_Interface

links to relevant user data, bugs, reports, examples, etc

To actually see the registration in action, go to [1] and select one of the web mail handlers. After you've accepted the registration, click the test link. It should bring up the compose window for the webmail app, though the header fields will not (at the moment) be populated correctly. Another example is to click on a webcal: link in a nightly; this will take you to a test handler that we have set up.

• Current dialog behavior is suboptimal; filed bug 402771 to sort this out.

Design Impact

Security and Privacy

• What security issues do you address in your project?
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
  • mime-types.rdf corruption / missing
    • will use reasonable defaults
  • application pref file (firefox.js or equivalent) missing
    • falls back to secure config (everything blacklisted)
  • user prefs.js missing
    • falls back to default config (believed secure)
• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • Assumptions
  • Capabilities
  • Potential Risks
    • Phishy? (Encourages in-browser auth?)
      • not notably worse than current situation
      • should avoid breaking future identity/auth mitigations, but not knowing what those are likely to be makes this hard
    • The HTML5 spec has a list of possible security issues that should be gone through
      • spec: "should NEVER send https URIs to third-party sites"; filed bug 402144 filed
      • need to handle Intranet URI leakage as per HTML5 4.10.2.1; filed bug 402138
      • Leaking credentials; filed bug 402152.
      • Need to be sure only appropriate handlers can be overridden; filed bug 402788.
      • Done; things we need to address now accounted for in this document with bugs filed.
    • register{Content,Protocol}Handler should be restricted to http and https handlers (bug 401343)
    • Need to decide on uses of web-handled URIs in contexts other than in href attribute of A element (bug 400886)
    • old warning dialog has been removed; filed bug 402151
      • • if it's unacceptably risky, we shouldn't be doing it at all
        • unclear how much a warning dialog helps anyway
    • non-SSL handlers in combination with DNS MiTM attacks (eg bogus Wifi APs)
      • a problem, but not of the magnitude of add-on downloads, because this code doesn't execute locally with privs. Decided to continue to allow handler sites to determine whether or not to require SSL.
  • Misc
    • notification bar for handler registration insufficiently clear; filed bug 402245
    • details and editing of handler info not available from prefs UI; filed bug 402252
    • web-based protocol handler "already been added" UI could use some tuning; filed bug 402258
    • a rogue site could trick a user into registering a handler that would go to a large mail site (e.g. Yahoo mail) but via a redirector that could then sniff all requests; filed bug 402287
    • verify that we don't leak various information; filed bug 402641
    • need to decide on best behavior re opening in new tab/window; filed bug 402736
    • there are some more bugs that need to be filed; dmose is working on paring down this; these are unlikely to be blockers:
      • allow user to say "no and never again"
      • credential leakage; url -> handler (yes for fx3), web page -> handler (no for fx 3) verify
      • filter URI specs based on spec-specific criteria: X- headers out of mailto
      • enforce URI syntax restrictions
      • test registration spamming
      • RDF serializer should be audited for quoting

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • APIs
    • exported to the web: navigator.registerProtocolHandler, any URI referencing attribute (href, src, etc.)
    • exported to XPCOM: nsIHandlerInfo, nsI{Web,Local,}HandlerApp, nsIHandlerService
  • UI -- see the UI design documentation section
• Does it interoperate with a web service? How will it do so?

Yes, as per the WhatWG spec. It simply url-encodes the URI to be sent, and replaces the "%s" in the handler string with that in a GET request.

• Explain the significant file formats, names, syntax, and semantics.

mime-types.rdf has been extended slightly to allow for multiple possible application handlers per type, and for support URI schemes in addition to MIME types. The mime-types.rdf handling code has been largely contained behind well tested interfaces. At some point, the hope is to replace them with a mozStorage database instead.

• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

Yes, in the IDL. They are not documented on devmo.

• Does it change any existing interfaces?

Yes. nsIMIMEInfo now inherits from nsIHandlerInfo; nsIHandlerInfo can also be used directly to represent a protocol handler. Furthermore, the old hidden prefs for protocol handling app configure on Unix have been removed, now that there's UI for this.

Web Compatibility

• Does the feature had any impact on Web compatibility?

I can has no impact.

Performance

• How will the project contribute (positively or negatively) to "perceived performance"?

Web-based handler apps will typically be significantly slower than local handler apps.

• What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?

In general, launching any handler is a very rare occurrence, and the minimal cycles taken on the Mozilla side will lost in the noise of the app startup time, whether local or networked. No quantification of this has been attempted.

• Will it require large files/databases (for example, browsing history)?

No.

Reliability

• What failure modes or decision points are presented to the user?

Hitting any sort of connectivity error while attempting to connect to the web handler behaves as one would expect (i.e. shows a network error page). At some point in the future, we'll probably want to ensure that it's possible to write web-based handlers that work entirely without touching the network. This might involve pinning them to the cache somehow.

• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

None known; no cleanup necessary.

l10n and a11y

• are any strings being changed or added?

Yes; the strings from the new dialog have recently been moved to localizable place.

• are all UI elements available through accessibility technologies?

Unknown. Need to file a bug here.

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

• Does it equally support all Tier-1 platforms?

Yes, modulo the special application selector, which is currently only available for Windows (other platforms get a native filepicker). Bugs are on file.

• Does it have a hardware requirement (or increase minimum requirements)?

No.

• Does it require changes to the installer?

No.

• Does it impact updates?

No.

• list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

Upgrade: new default web-handlers may be injected (i.e. automatically registered as possible handlers) into existing mime-types.rdf databases. Downgrade: functionality will disappear, old version will work as previously. Reinstallation of the same locale will notice that new protocol injection has already happened, and not try to inject again. Reinstallation of a different locale may get confused; bug 395277 on file about that.

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

Yes. In the case of accepting protocol handlers being registered for web-sites, there is a notification bar. The new protocol handling dialog offers choices as needed for URI schemes whose handling is not already defaulted. There is preferences UI to manage how particular schemes are handled at any time. There is not, and perhaps should be, any way to remove already accepted web-handlers from the preferences and dialog.

• Are there build options for developers? [#ifdefs, ac_add_options, etc.]

If MOZ_RDF is not defined, web-based protocol handlers will currently fail. There are no options specific to this feature.

• What ranges for the tunable are appropriate? How are they determined?

There are currently no real tunables. There is a [wanted-firefox3] bug for experimenting with giving the dialog / dropdowns some MRU list love, which would probably introduce a few tunables.

• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

None currently.

Relationships to other projects - are there related projects in the community?

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

We are implementing the proposal from the WhatWG HTML5 spec, so we depend on them. However, as the first known implementor, we're feeding back comments to their mailing list in an ongoing way.

• Are you updating, copying or changing functional areas maintained by other groups?

No.

Documentation

• Do built-in Help pages need modified?

A coin toss. There was no documentation for the old protocol handler dialog, but that one was pretty simple. We could potentially add some, but even the new dialog isn't terribly complex.

• Documentation for developer.mozilla.org?

Basic documentation for navigator.registerProtocolHandler exists. We hope to ask the evangelism team for some cycles to put together a small tutorial on building an example server-side protocol handler.

Other

Other issues to check: non-idempotent URI types

Discussion & Implications

Caveats / What We've Tried Before

• The old protocol handling dialog was a simple nsIPrompt which only allowed things to be handed off to the system default. The new dialog is essentially a cleanup and evolution of unknown content-type handler dialog for MIME-types. In a future version, the plan is to use this new dialog to replace that old one too.
• In bug 380415, the backend changes were originally done as a redirect on the nsExtProtocolChannel after AsyncOpen was called. This had some structural problems, so the code got pushed into the nsHandlerInfo::LaunchWithWebHandler where it switched to simply creating a new channel and sending it to the URI loader. Further refactoring pushed this into nsIWebHandlerApp.launchWithURI where it really belongs.

References

The MIME Edit addon has some example UI that is more complete than the Firefox 2 UI, though not particularly friendly to non-technical users.

WhatWG Web Applications spec

API request from an extension author for dialog extensibility