Firefox/Feature Brainstorming:email

Email Address Handler

Currently, whenever an email address link (e.g. mailto:example@example.com) is clicked, a message is composed via the client's default email application (Thunderbird, Outlook, etc.). A better feature would be for the Firefox browser to overload this feature with the ability to trigger a new email to be composed through a webmail application as well (Gmail, Yahoo, Hotmail, etc.). This feature would work similarly to the RSS reader feature inherent with the latest versions of Firefox, which allows you to subscribe to an RSS feed via multiple services.

The handler would also give the user the ability to send an email through their default client application, and depending on their profile in Firefox, they would be able to specify a default email provider.

Agree it's years overdue for browsers to tackle and solve this.
Hotmail launched in 1996, fer cryin' out loud!  :-)

Draft implementation suggestion:

• Under Tools:Options:Advanced, add a new tab for e-mail.
• Under this new tab, provide a pop-up menu that allows the user to specify what to do when a "mailto:" link is clicked: e.g., "use default e-mail client", "use e-mail service below", "copy to clipboard", "do nothing" (three of those would be an immediate improvement right off the bat).
• Choosing "use e-mail service below" would enable a scrolling list of supported services, with any user-added profiles sorted at the top, followed by built-in profiles, perhaps sorted in descending order of popularity. (Or, with a "More..." button that expands the list to include more esoteric services.) Each service might also have an "include in context menu" checkbox.
• If the user selects one of the user-added profile (if any), a minor button would be enabled to submit that profile to Mozilla.org as a suggested addition to the built-in profiles (a la GraceNote). This way, anyone capable of inspecting HTML and editing XML could help expand Firefox's list of built-in e-mail service profiles, even if an interface for that purpose is never added to Firefox.

The list of profiles would be populated/enumerated from one or two XML files (e.g. one XML file for built-in e-mail service profiles, and another XML file for user-added e-mail service profiles). The XML files would contain sections for each e-mail service, with fields such as:

• "Display Name" of the service,
• "Domain(s)" of the e-mail service (perhaps with wildcard support for ones that use unobscured server farms -- e.g. "www*.cooliomail.com"),
• "Compose URL" link used to start a new e-mail on the service (perhaps with parameter support -- e.g. "https://www.cooliomail.com/compose.asp?address=[mailto]&subject=[subject]"),
• "Compose Frame", with the name of the HTML frame in which that service displays its compose e-mail interface (if any; "_top" is assumed), and
• "Address Field", with the name of the form element where addresses are entered on the compose page. (If the e-mail address can be specified via a parameter in the "Compose URL" link, specifying this field would be unnecessary.)

Then, if the user clicks a mailto: link after enabling the "use e-mail service below" preference, Firefox would:

• Look for currently open windows or tabs with a location URL matching any "Domain(s)" for the service specified in the XML file, and -- if any are found -- determine which of the matching windows or tabs the user opened earliest, and bring that one to the front.
• If no window or tab matches the "Domain" for that service, Firefox would open a new window or tab, bringing it to the front.
• In the window or tab that's now frontmost, Firefox would navigate to the "Compose URL" for that service, specified in the XML file. If a "Compose Frame" is specified for that service in the XML file, and a frame with that name already exists in the frontmost window, "Compose URL" would be targeted to that specific frame. (If the user isn't already logged into the service at this point, the service will likely bounce them to the sign-in page for the service.)
• As the "Compose URL" page is rendered, Firefox would monitor the DOM for creation of a form element with a name matching the "Address Field" specified in the XML file. When that form element is created, Firefox would set that field's initial value to the "mailto:" address provided by the e-mail link. (Alternately, Firefox could scan incoming page source for INPUT tags where the "name" attribute equals the "Address Field," and insert or replace the "value" attribute for that tag on the fly to insert the "mailto:" address.)
• If more than one form field with that name is detected, any form field with that name found within a frame matching the "Compose Frame" would take precedence, and any other field with that name already modified would be reset to its default value. (In this way, Firefox wouldn't have to wait for the page to completely finish loading to inject the e-mail address. Sometimes pages are complete enough to be functional, yet don't finish loading for some time -- if ever -- due to a missing response or timeout from one Web server or another.)

Other features this might support:

• File menu command and keyboard shortcut for "New e-mail".
• Expanded (second button) context menu for mailto: links with sub-menus so the user can choose to begin the e-mail in any installed e-mail program, or any supported Web-based e-mail service that has been marked "include in context menu" in the preferences dialog described above.
• If a default Web-based e-mail service hasn't been selected, and the user visits a URL matching one of those in the XML service profiles, a "warning bar" might appear at the top of the browser window to ask whether the user wants to make this site their default e-mail service.

The context menu for mailto: links currently permits the user to "Copy Email address," and the user can then manually switch to (or open) a window or tab for their Web-based e-mail service, click the compose link for that service and paste the address from the clipboard into the "To:" field. But this is undesirable because:

• It involves many extra steps beyond what "mailto:" links were originally meant to require.
• Less savvy users may not be aware of the context menu, or puzzle out the necessary steps afterward, or even have a strong understanding of how to take advantage of copy and paste.
• There are many "stealth" mailto: links out there on the Web, not explicitly labeled with an e-mail address with an "@" sign, and that even power users may think lead to a form-based contact page. When users click on these links by mistake, they must wait for some e-mail client they never use to finish launching, then take a moment to close it, and finally be back to square one, deciding whether its worth the effort to e-mail the contact by going through the extra steps of copying and pasting the address to a Web-based e-mail client.