from "Mark H. Bickford" <email@example.com>
"is was brought up in the early days of the mail/news group: it is
not currently possible, in Comm. 4.x, to direct the client to use an
external mail program for mailto: tags, but still use the Communicator
client for news postings."
I'll add this:
It'd be great to have mailto: links be configurable to launch urls.
so mailto:firstname.lastname@example.org?cc=foo&subject=bar could become
setting target M15.
Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey
bug tracking radar. Even though these bugs are not "open" in bugzilla, we
welcome fixes and improvements in these areas at any time. Mail/news RFEs
continue to be tracked on http://www.mozilla.org/mailnews/jobs.html
Reopen mail/news HELP WANTED bugs and reassign to email@example.com
changing QA assigned to firstname.lastname@example.org
*** Bug 17923 has been marked as a duplicate of this bug. ***
This is a fab idea. Imagine the increase in traffic to Netcenter etc. if when
you clicked on a mailto: link and there was no mail configured, a dialog popped
"You have no mail configured. Would you like to open a free web-based e-mail
account which integrates with your browser"? [ ] Never show this dialog again.
A yes would take you to signin at Netcenter, and in future Mozilla would rewrite
mailto: URLs to use your account. You would make the interface open, of course,
so other mail companies could enable integration for their products, but the
advantage of being the "default" would be considerable...
*** Bug 35977 has been marked as a duplicate of this bug. ***
I'm marking this nsbeta2. Why? Because I think that, as I detailed, Netscape
have a massive commercial advantage, in terms of traffic to their portal, if
they implement this functionality. And how hard can it be? Replace the "No mail
configured" dialog box with a URL rewrite and possibly a "Do you want to open a
webmail account?" dialog box.
But then, they might just mark it nsbeta2-...
Putting on [nsbeta2-] radar. Not on exception feature list.
alt mail is way out there.
It is very critical for about 150 computers we have in my company. We are using
The Bat! (http://www.ritlabs.com/the_bat/index.html) with NN4.x with utility
which allows to run The Bat! when clicked on mail link.
Is it so hard to implement "mailto:" links opens default mail programm???
*** Bug 42614 has been marked as a duplicate of this bug. ***
email@example.com - the wonder of Open Source means that, if this is a priority for
your company, you can implement it yourself, rather than having to ask other
developers to do it for you :-)
The helpwanted keyword in this bug indicates particularly that outside help is
requested to implement this feature.
I'm wondering why I keep getting mail about this bug, when I'm not on the CC:
24614 wasn't really a repeat of this bug. But I'll leave it and explain it here.
Can we have a option to run a different mail program when mail is called from
mozilla. This option exist in IE and is very nice. I think it used to exist in
netscape 3 ??
*** Bug 43861 has been marked as a duplicate of this bug. ***
We (IBM) did some design work on selectable mail for Mozilla, but we decided not
to implement it as part of our contributions.
We are working to get this design in a state where it can be contributed to open
Yesss.... Big thanks to Big Blue... :)
I have placed the design at:
Sorry about some of the formatting.
Note that this design was done in February, so things in Mozilla might have
changed since then.
Nominating for nsbeta3. External mail program use is a much-requested feature.
Marking nsbeta3-. Still a feature, and we're way beyond the point where we're
taking new features. Nice idea for the next release.
*** Bug 56478 has been marked as a duplicate of this bug. ***
On this people complains as much as mem and perf... At least in Russia.
Can we decide smth with it?
Nominating for release.
Who should decide would it be in moz 1.0?
this is the famous "alt mail" feature.
I have no plans on working on this any time soon, but if someone else wants to
start on it, I'll be happy to help them get started.
for how this worked in 4.x
*** Bug 65466 has been marked as a duplicate of this bug. ***
Couldn't <a href="http://protozilla.mozdev.org/">Protozilla</a> be used for
resolving this bug? From their <a
href="http://protozilla.mozdev.org/examples.html">examples page</a> it seems
like an OK solution. Note that this is only a suggestion; I know very little
about Protozilla and I unforturnately don't have time to look into it myself. I
just hope to maybe point someone in the right direction.
R. Saravanan wrote on <firstname.lastname@example.org>:
> Yes, protozilla could be used to resolve this "bug".
Update on customizing mailto: protocol using Protozilla
(I don't whether this can be called a fix for this bug, since
Protozilla is not in the Mozilla codebase, but it is certainly
an alternative solution that works right now.)
If you wish to configure the mailto: protocol to load a specific
URL, all you need to do is to create a file called "mailto.url"
using Protozilla containing a line like the following
This takes me directly to Yahoo mail when I click on a link like
(NOTE: The magic number f33 may be different for other users.)
The above example is included in the latest version of Protozilla,
under the name "mailto-y.url". There is also another example,
"mailto-h.url", which works for Hotmail. It illustrates how you can use
Protozilla now also supports launching of "helper" applications
for designated protocols, as was the case in Netscape 4.x
For example, you can create a protocol handler file named
"mailto.cmd" containing the following line
This will cause the command "mail user@host" to be executed
when you click on mailto:user@host
There is an example called "telnet.cmd" included with Protozilla
to illustrate helper application use.
CAUTION: If you override the mailto: protocol using Protozilla, and
later wish to restore the default behaviour, you will need to delete
the file named "component.reg" in the mozilla binary directory.
If someone knows how to get around this problem, please let me know.
Thanks for the info svn. You rock!
Note that the mailto: URI type covers much more than just the recipient. IIRC,
you can specify arbitary headers with ...[&]Headername=headercontent, e.g.
<mailto:email@example.com&Subject=Hello%20you!>. Note the escaping.
(Disclaimer: I still havn't checked out Protozilla yet. Sorry, if it's already
in the examples.)
If one uses Protozilla to redirect the mailto protocol, does this disable
posting to newsgroups from mailnews? That was the difficulty with Communicator:
redirecting the mailto protocol to an external client made Messenger try to use
that client whenever posting to news was invoked, and that is why I made the
posting that Seth used to enter this bug.
I just checked. Redirecting mailto: using Protozilla doesn't seem to affect news
Re: mailto: being able to launch a URL instead of an external mail application.
This could have some bad implications for usability or security. The URL
parameters in a mailto: link are for setting header values in a mail message. The
URL parameters in an http: link are for setting CGI parameters and the like.
Mixing the two could cause problems.
firstname.lastname@example.org - I don't understand how it could be. Could you give an
example of how this might be a problem?
Re: the above request for an example. Consider:
A mail application that handles mailto: links properly won't attach the
signature or set the Reply-To header (see the mailto: spec, RFC2368 at
http://www.ietf.org/rfc/rfc2368 ). However, a Web mail application might well
allow either of those options to be set via URL parameters.
Or consider the more malicious
This is not a new risk; if the user is already logged in to the Web mail account
a Web author can just do
However, by providing a feature for always pointing mailto: at a URL, you would
be encouraging users to leave themselves logged into their mail accounts, and
thereby leaving themselves vulnerable to this kind of malicious URL. Some people
may find this acceptable, but others (including novice users) might not know
there is a risk.
The plan, surely, is not to automatically convert all link parameters to a
same-named CGI parameter, but the Protozilla script (which would be
(to, cc etc.) and convert those to whatever that webmail provider's URL params
ok, I didn't realize that from the earlier comments
The sample implementation of mailto: URLs bundled with Protozilla handles only
the "To" field at the moment. Ben Bucksch suggested that perhaps we should
implement more features, as in RFC2368. The comments regarding the security
issues suggest it would be wise to support only a restricted implementation of
mailto: URL redirection in Mozilla. If you look into the HTML source for web
mail interfaces at Yahoo and Hotmail, they too support only restricted "mailto"
*** Bug 76237 has been marked as a duplicate of this bug. ***
*** Bug 88061 has been marked as a duplicate of this bug. ***
RESENT QA and owner: pmock is gone.
Comments in Bug 56478 suggest that having mailto: use the default OS mailto:
handler might be coming soon.
This bug is really too open ended, and should be divided in to several bugs:
1- mailto: -> some app (via OS or mozilla pref selection)
2- mailto: -> arbitrary URL (via Protozilla?) + security issues
3- how to do this to mail vs. news (for those who want to use mailer "a" and
newsreader "b"). (IE does this).
I say, make this bug #2, and deal with #1 in Bug 56478. Create a new bug for
#3, or find a dupe that mentions it an re-open.
*** Bug 94295 has been marked as a duplicate of this bug. ***
*** Bug 94777 has been marked as a duplicate of this bug. ***
Marking mostfreq to avoid dupes (since NN6.1 I heared it many many times).
BTW Any news here?
mostfreq is deprecated.
benc: 1, 2 and 3 can all be solved using Protozilla, as I understand it.
Saravanan is working on getting the IPC stuff in at the moment.
I hope this may help some people, who want to use another mail client AND
another news client on Windows.
If you do not install Mozilla's mail/news component, then 'mailto:' and 'news:'
URLs are handled by the OS default program, otherwise Mozilla will ALWAYS use
its own mail/news client.
Unfortunately I don't know a way to deactivate or deinstall the mail/news
component after installation. This also applies when you 'install' Mozilla
through the non-installer ZIP archive.
So deinstall/remove Mozilla and reinstall the wanted components (e.g. select
browser only) WITH the INSTALLER VERSION.
This does NOT make the need for an alt_mail/alt_news definition obsolete.
Any help about deactivating/deinstalling a component after installation is
*** Bug 103567 has been marked as a duplicate of this bug. ***
*** Bug 106422 has been marked as a duplicate of this bug. ***
See also converse bug 108455, "need option for links in moz mail to open in a
I want to user Mozilla News for 'news:',
but I want to use External Mail client for 'mailto:' url.
A way of deactivate the mail/news component can not satisfy this proposal.
I want to support a way of changing default URL handler.
What is the option 'Use Mozilla Mail as the default mail application' in
Mail & Newsgroups in preference ?
This option is exist, but not be clicked still.
If you get round to implementing this, might I suggest you make it configurable
(after installation) by ISPs and so on, after the fashion of Micro$oft .ins
files? This would allow ISPs, etc. to include a link such as 'Click here to
download a file to make Mozilla use our webmail as your default mail client'.
- with the appropriate security precautions, confirmation, etc. of course.
us your default mail client</A>
Note the use of $XXX$ placeholders in the URL - this would allow webmail
providers a good degree of customisation depending on their system. I would
suggest the following fields be allowed (although there may be more I haven't
login (this is the user's login to authenticate with the server)
password (user's password to authenticate with the server - not sure if this is
a good idea or not)
Should this actually be listed under MailNews?
I typically have several email accounts, and I actually find it worthwhile to
have several mail user agents, each configured to a variety of different mail
For example: I am now trying out Mozilla once more. One day I look forward to
importing all my email from Eudora into Mozilla, but that's not for today.
Today, I would like to have Mozilla handle my spam mail account since I suspect
that Mozilla's security will be better than Eudora's security since Eudora uses
IE to display html email.
So I want ALL mailtos to be handled by Eudora. I do want Mozilla's email client
installed, and I want to explicitly bring it up to send/respond to mail sent
to/from suspected spamming companies.
It shouldn't be all or nothing. In short, is there any reason that Mozilla
doesn't respect it's own setting: "make mozilla the default mail agent: NO"?
*** Bug 120713 has been marked as a duplicate of this bug. ***
*** Bug 121197 has been marked as a duplicate of this bug. ***
*** Bug 121224 has been marked as a duplicate of this bug. ***
*** Bug 124417 has been marked as a duplicate of this bug. ***
*** Bug 124812 has been marked as a duplicate of this bug. ***
*** Bug 125932 has been marked as a duplicate of this bug. ***
*** Bug 126825 has been marked as a duplicate of this bug. ***
*** Bug 132276 has been marked as a duplicate of this bug. ***
Sorry for the spam, but I talked to many Moz and NN users and 95% of them use an
external mail programm. They all use Right-click -> Copy E-Mail and CTRL-V in
Now we can imagin how many people stopped using moz/NN since they does not allow
of using external mail client.
I believe it must be in moz1.1
*** Bug 134515 has been marked as a duplicate of this bug. ***
Will this be fixed in 1.0?
I think we can safely say "No". Sorry.
removing nomination for 0.9.8 - long since passed
*** Bug 138513 has been marked as a duplicate of this bug. ***
*** Bug 140285 has been marked as a duplicate of this bug. ***
Why can windows users customize the installation of Mozilla with the option of
installing the the navigator, mail, news, etc. But mac users have to install teh
whole thibng? Too bad im not an amazing enough programmer to fix it myself! :(
I'm not sure if this applies to all builds of Mozilla or just the Mac OS X
build, but adding a file called user.js to your profile folder (the same folder
contains prefs.js) and placing the following text in that file will fix this bug:
From what I understand, this also works for ftp and nntp. This was pointed out
to me by someone in the netscape.public.mozilla.macosx newsgroup. Is this just
for Mac OS X, or does it apply to the other builds?
Works for Mozilla 1.0 RC1 on WinXP. :-)
Sadly, this workaround does not appear to work under Linux (RedHat 7.2 with
Ximian Gnome). It _does_ prevent Mozilla Mail from running but does not invoke
the corresponding Gnome URL-handler. If it's trying some other handler
mechanism, I don't know what it is. I looked through a fair chunk of source to
see if I could figure out what Mozilla calls but I couldn't find the
platform-specific URL handler stuff (never looked at Mozilla source before). Alas.
I did run into a fair number of "obsolete" designations so I doubt this
mechanism is going to stick around.
Platform-specific URL handlers are implemented in nsOSHelperAppService.cpp
(there are win/mac/os2/unix versions of this file with different implementations).
In particular, the Unix version is not implemented:
An implementation is being done by Michael Kaply in bug 33282. It will allow
setting Mozilla preferences to run helper applications for various protocols.
It will _not_ read the Gnome preferences, obviously.
A separate bug should be filed on reading the Gnome URL-handlers (please cc me
on it). Hopefully there is a way to do that without compiling against a gnome
header... (but I have my doubts about that).
Works like a charm in OSX! :)
It would still be great to uninstall the mail component to save memory but its
pretty convenient not having to copy/paste email addresses anymore!!
Posted bug 140635 about using GNOME URL handlers. (Thanks for the pointer, Boris.)
*** Bug 136682 has been marked as a duplicate of this bug. ***
Woohoo, comment #72's fix solved the problem. This is wonderful, I'm in heaven.
Now I can use Mozzilla as my primary browser.
Tried #72, but it didn't fix my problem. :-( I just created a simpletext file
with the line as instructed--is there some other way to do it? I'm on Mac OS 9.1.
This might not work in OS 9, but it works fine in OS X. This might not be
implimented yet in OS 9.
I got mailto to work in Win2k by using pres.js! Thanks
Is there a way to make Send Page and Send Link use the external mail app as well?
For those of you who have implemented the fix in Comment #72, can you confirm
that you can still use Mailnews to post to newsgroups, even with the alternate
mail client enabled? That was the original bug from 4.x (at least on Windows):
you could redirect the mailto: handler to an external app with nsmapi.dll, but
then Communicator would launch that app when you tried to post to a newsgroup
I can confirm that the fix in comment #72 only affects mailto, newsgroups will
open in mozilla (Win95, moz 1.0 RC1).
Substituting nntp for mailto, will however make mozilla crash when you try to
view newsgroups :-(
Should the relnote keyword should be added to this bug since it has been futured
Also, setting this preference has no effect on nttp protocol handler for OS X:
it just causes the throbber to flicker uselessly either way. Will hunt to see
if that bug has been entered.
Using the patch at bug 33282 it is now possible to use an external mailer on Unix.
After applying the patch, try the following in prefs.js:
user_pref("applications.mailto", "rxvt -e mutt");
A similar setup should work for any mailer that will take an address as a
Re: Comment #86, many thanks. This worked in Moz1.0.RC1 under WinNT and got my
Eudora working (as specified in Control Panel>Internet). (Hmmm, it must've
ignored the "applications.mailto" lines [not using 'rxvt', that's for sure]).
if you don't install mailnews then on windows we will farm out mailto: to
whatever app has registered it.
It would be great if there was a UI for this. Perhaps:
| [ ] Make Mozilla my default email program.
| Clicking an email link from Navigator opens:
| ( ) Mozilla Mail
| ( ) Your default email program
| [ ] On startup, check if other programs changed
| this setting
If the first checkbox is checked, then the two radio
buttons should be disabled.
If the first checkbox is cleared, then the second
checkbox should be disabled.
What do you think?
netscape1.0's ui was far superior
Does Comment #86 still work with RC2 ? I added the user_pref() lines to my
prefs.js, but nothing happens when I click on mailto: links. (telnet: links
don't work either)
alexander, if you're using linux, comment 86 only applies if you compile mozilla
yourself and have applied the patch from bug 33282
*** Bug 143944 has been marked as a duplicate of this bug. ***
Adding the line of text suggested in comment #86 to my prefs.js file worked just
peachy on OS X (so adding the user.js isn't necessary, fwiw).
This begs the question: Why isn't there a UI for this? It probably doesn't
need to be the one in comment #89, though I personally didn't really see much
wrong with that, but *some* way for Joe Blow to use another email client is
prefs.js is *not* the place to add that.
prefs.js is "property of mozilla" in the sense that it can re-write and mangle
the file in any which way it chooses. Your pref could one day vanish.
user.js is "property of the user" in that mozilla will not mess with it. Put
your custom funky stuff in the user.js file :)
It may never matter, but if you put it in user.js, then you don't need to worry
about the phrase "*may* never matter".
See also bug 96717, Mozilla mailnews never registers mailto: protocol with Windows.
works great for me now. How do I get off this mailing list?
*** Bug 144484 has been marked as a duplicate of this bug. ***
*** Bug 146218 has been marked as a duplicate of this bug. ***
*** Bug 150979 has been marked as a duplicate of this bug. ***
*** Bug 153357 has been marked as a duplicate of this bug. ***
*** Bug 153420 has been marked as a duplicate of this bug. ***
Tried comment 72 and comment 86 and still Netscape Email client opens on mailto
links for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1)
I apologize if this is the wrong place for this, but the problem description
*** Bug 154582 has been marked as a duplicate of this bug. ***
Re Comment #103:
NS 6.2 is to old for this to work, update to NS7b1 or Moz 1.0 or 1.1a.
*** Bug 155731 has been marked as a duplicate of this bug. ***
*** Bug 157363 has been marked as a duplicate of this bug. ***
Why is this marked as a mail bug and not a browser bug? Why is it worded as a
request for a preference when it's really a bug about not honoring preferences
set in the operating system?
> Why is this marked as a mail bug and not a browser bug?
Good question. Looks like a browser bug to me.
> Why is it worded as a request for a preference when it's really a bug about not
> honoring preferences set in the operating system?
Severity is 'normal' not 'RFE'. As to the OS preferences, the problem is twofold:
1) Moz doesn't register itself as the mailto: app - see bug 96717
2) Moz ignores the registered mailto: app
*** Bug 160263 has been marked as a duplicate of this bug. ***
It's assigned to "nobody"?
I think that's because it was just moved from MailNews to Browser the day before
yesterday, and nobody's had a chance to pick it up yet.
no, it was intentionally reassigned to nobody when it was moved
-> email@example.com (as default owner)
When the Mail prefs are canceled out the entire browser crashes in OSX
*** Bug 160894 has been marked as a duplicate of this bug. ***
*** Bug 161690 has been marked as a duplicate of this bug. ***
This is the ONE outstanding Mozill,a bug that prevents me from using Mozilla as
my default browser. When I click a Mailto: (Mac OS X) I want to launch my
prefered mail app. Under Mac OS, that preference is stored in my Internet
settings and is available to all applications. I want to launch Eudora, or
Mail.app, or... whatever _I_ prefer.
Sorry, but to me, Mozilla is a web browser; I can view News via the web. Mozilla
is not now and never will be my mail client.
Please fix this.
Vicki, did you read comment #72?
Every comment speaks about "the default mailer of the platform". But my platform
(linux) has *no* default mailer. So I need a way to specify this inside mozilla.
With communicator I would have used muttzilla, but this does not work anymore...
See bug 33282. That would let you define a mailto: handler.
33282 is a telnet handler bug...
Besides, those of us on Mac OS already _have_ a mailto handler defined; Mozilla (like IE
:-) only needs to _use_ the definition already available!
I Missed COmment #72 in the myriad morass of comments; however, comment #72
(presuming it works) is not a solution; it's a workaround. I want an interface and a
preference that works every time. When I re-install Mozilla my user.js file is overwritten
(and besides taqt, getting to it to edit it is painful at best). This should _just work_ for
those of us with Mac OS (does Windoze have a default mail app sett9ing?) and for those
with Linux there should be a pref to set a mailer.
> 33282 is a telnet handler bug...
which you obviously did not read. It sets up a generic mechanism for defining
handlers (protocol --> helper associations).
> When I re-install Mozilla my user.js file is overwritten
It should not be. If it is, please file a bug on installer.
This is not to say that we should not respect that setting by default on Win and
Re: comment #124
>> When I re-install Mozilla my user.js file is overwritten
>It should not be. If it is, please file a bug on installer.
Installer? What installer? There is no "installer for Mac OS X... it's a drop-in folder
That should certainly not clobber user.js... Does it overwrite your bookmarks
too? Those two files are both stored in the user profile, not in the Mozilla
BugZilla is not a tech support forum. It is here to track work of developers. If
it works for you, fine, if not, bad luck and just wait or pay someone to do it.
*** Bug 167273 has been marked as a duplicate of this bug. ***
Comment #72 is a nice quick fix, but I really would like to see a nice UI for
*** Bug 170502 has been marked as a duplicate of this bug. ***
*** Bug 174285 has been marked as a duplicate of this bug. ***
*** Bug 175339 has been marked as a duplicate of this bug. ***
*** Bug 176494 has been marked as a duplicate of this bug. ***
*** Bug 176965 has been marked as a duplicate of this bug. ***
*** Bug 177136 has been marked as a duplicate of this bug. ***
*** Bug 181130 has been marked as a duplicate of this bug. ***
*** Bug 185114 has been marked as a duplicate of this bug. ***
*** Bug 188008 has been marked as a duplicate of this bug. ***
*** Bug 188295 has been marked as a duplicate of this bug. ***
*** Bug 188705 has been marked as a duplicate of this bug. ***
Cool, thanks, http://bugzilla.mozilla.org/show_bug.cgi?id=11459#c72 worked fine.
It's too bad this isn't a pref. This work-around works great, but it
s a little sloppy...
There's no way I would have found it without being told where it was.
I was going to go back to IE, I'm glad this saved me from having to do so...
Maybe someday, with as mant posts as there about this, someone will fix it.
I would if I knew how, but maybe it would be a good idea to include this fix as
a text file with the distribution.
It's the only thing that kept me on Mozilla!
Had you read the FAQ at http://www.mozilla.org/start/1.0/faq/mail-news.html#3.3
you would have known it.
Also, it applies only to Windows and MacOS.
It only works for windows/Mac OS and the additionnal comment is frioghtening :
Unix/linux is NOT limited to GNOME/KDE.
My two cents after reading this.
1. It doesnt' seem to be a big issue to the Mozilla people - but it needs to
be! Frankly, I - like many others - use other mailers and we have not gone to
Mozilla for this reason - can't use our mail client. If I could have my mail
program (sylpheed-claws) be used as the mailer I'd use Mozilla all the time.
2. I've installed it without the mail and other stuff but still didn't work.
Also, in some packages you don't get a chance to weed out the mozilla mail stuff.
3. The patches listed here did not work - mozilla 1.2.1 on 2.4.19 kernel.
This is another vote (someone in one of the bug replies said they needed more
input on this because they didn't think it was an issue) for the ability to use
an external mailer.
*** Bug 190570 has been marked as a duplicate of this bug. ***
*** Bug 191980 has been marked as a duplicate of this bug. ***
*** Bug 195296 has been marked as a duplicate of this bug. ***
Perhaps we can wait until Apple Safari is out of beta.
I cannot believe Netscape/Mozilla want's to FORCE their mail and news client on
users without choice. This is Microsoft's M.O.
Also, I'm kind of getting sick of the "This application has unexpectedly quit"
It's too bad. I love the tabs, and would use it for that alone if it didn't
screw up my ability to use email, and if it didn't crash all the time...
*** Bug 198631 has been marked as a duplicate of this bug. ***
I am hesitant to throw in a "me too" if only for the length of the discussion on
this bug, but as no one seems to have mentioned it, this is a more crucial bug
for phoenix users, as no mailer is included with phoenix (which is part of why I
use it.) I've seen the notes on how to compile in my preferences, as well, but I
use gentoo and there currently is no phoenix package in gentoo's portage tree
except phoenix-bin (binary, obviously,) and prefer not to install apps without
portage. My own preference, I know, but I'm not the only phoenix user out
there...in the end though, this is only my $0.02.
I hope this will ease the burden on this bug some. Quite a few issues that are
addressed in here come under the headings of other bugs.
The one issue raised in this bug that I have not seen covered elsewhere is
the conversion of a mailto: link to a Webmail http: link. I'm not sure whether
that is an internal function of Mozilla; or if it would be farmed out to an
external program, in which case it's the same as the issue discussed below.
The most talked-about issue in this bug is that "Mozilla doesn't open my external mailer when I click a mailto: link." Bug 144828 (for Windows and
MacOS X) supplies the same solution as put forth in this bug: "Set the
net.p-h.ext.mailto pref to true." (Which does not work for the reporter of
that bug, who's using NT4, but seems to work for everyone else who's tried it.)
Bug 56478 addresses the same issue for Linux, which does not necessarily have
a "default mailto handler" like Win & OSX; and bug 140635 addresses using the
Gnome scheme of default URL handlers.
Other issues discussed in this bug:
Why doesn't Mozilla default to using the external mailto?
this is Bug 196798 (asking for the pref to be True by default); note that,
at least in windows, we currently DON'T want it true by default, if Mozilla
is the preferred mailto handler: Bug 198547.
Why is there no UI for the net.p-h.ext.mailto pref?
I don't know of any bug that specifically asks for this; bug 96717 is close,
and I will add comments to that effect there.
Can Mozilla use an external mailer for its Send Page and Send Link menu items?
this is Bug 152526.
Why doesn't Mozilla register itself as a mailto handler when it sets itself
as the default mailer?
this is Bug 141965.
Overall, I'm not sure this bug should even be kept open, except perhaps for the
webmail support; all its issues are dealt with in other bugs, all of which
are shorter and easier to read.
If a GNOME solution is acceptabler for Galeon, it is NOT a solution for mozilla,
except if you make mozilla a GNOME only browser. The only possible solution is
the possiblity for the user to define his/her own way of handling mailto,
independently of any external environment. UNIX (and not only Linux) is not a
And I should add that a web mail is neither a solution for everybody, since not
evrybody subscribes to such a service.
Based on comment 151, I have added bug 198547 and bug 196798 to the dependency
list for this bug. If they are both fixed, this problem will be resolved for
MacOS and Windows. If bug 33282 is resolved, then fixing the two previous bugs
will also resolve this problem for Linux users.
I would say that the most expedient method of handling this bug for the majority
of users would be the resolution of bug 198547 and bug 196798.
I'd rather close this bug than to turn it into a tracking bug. It gives the
impression that this is not working at all (see the rants above), while in fact
it does for many (most?) cases, it seems.
With Firebird/Thunderbird even Mozilla's mail app is external, so probably bug
196798 is going to happen for 1.5a. So if there's ever going to be a pref UI
for folks using the Mozilla 1 series it needs to get into 1.4. If it's not
going to get into 1.4 that's effectively WONTFIX.
Marking blocking1.4b? for somebody to decide.
I think comment 154 misses the point of my 151. (For that matter, so did 152 &
153.) I think those other bugs stand on their own, and are separate from the
issue of "need[ing an] option for mailto: to launch [an] external mail app."
That option exists (well, maybe not for *nix), altho it is not yet automatic,
cleanly specified in the Moz UI, or bug-free.
The one issue described uniquely here and still unaddressed: converting a
mailto: URL into a Webmail http: URL. That is most of the issue described in
the original report.
I'm not sure this should be built in to Mozilla, tho. I think a helper app
makes a little more sense. (Maybe a mozdev project, or better, an app provided
by the Webmail vendor.)
This program would be linked to mailto:, accept the mailto: URL, convert to an
http: URL to the mail-compose page of the user's webmail account (and I assume
there are many such URL formats), and feed the URL back to Mozilla (or maybe
even to another browser, if the user so desired -- say they use a webmail
servuce that relies on IE-proprietary features).
UI issues of whether that page should go into the original tab, into a new tab
or into a new window would need to be hammered out; also, how to handle the case
where the Webmail account needs to be logged into before the compose page can be
I disagree with comment 157. The issue is still open. Unix Users (and maybe
others, I think to people using a text mode mailer like mutt under windows) have
no possibility to use an external mailer.
This mailer being a webmail url handled by mozilla or another application is
another problem. The need is to be able to specify a mailer.
I agree with Erwan David about that. This bug should depend on Bug 33282. (See
comments there, 44 & 45, about how it is not Linux-specific but all Unixes.)
But I don't think most of the current dependencies actually, validly, block this
- Bug 68406 is about adding new (user-specified) protocols to Mozilla's list;
Mozilla already knows what mailto is
- Bug 96717 is about Mozilla registering itself as the system mailto handler
- Bug 198547 is specific to a condition where Mozilla is the default mailer.
(And it blocks 196798 already.)
Bug 196798 is about defaulting the net.p-h.ext.mailto pref to True, which would
help this bug, but (until MailNews is a separate app) is not necessarily the
right thing to do. Revising my opinion from comment 156, this is a valid
Should the Webmail thing be broken into its own bug, which this could then also
be dependent on?
So this bug got a - on blocking1.4b. Since 1.5a will use an external mailer,
should it just be resolved WONTFIX then?
> Since 1.5a will use an external mailer,
It will? It'll be moving that way, but possibly not done yet... Also, iirc
there will be the option of installing Minotaur as an extension, not just a
standalone app. And then the problem continues to exist.
Ah, I'm sure you know more than I do - the development roadmap just talks about
stand-alone browser, stand-alone mailer.
*** Bug 203542 has been marked as a duplicate of this bug. ***
This is bigger than just email, the entire set of options to launch external
programs is missing. The available items in IE are HTML Editor, Email,
newsgroups, internet call, calendar and contacts and these probably all apply
except maybe calendar (although that might be nice too) and Mozilla should
provide for alternative executables for all of these. This is a great feature
and it would suck if only MS had it, NO???
First, I have to admit I´m only a user, not a developer. Recently, I gave up
Opera because V7.x doesn´t support my mousewheel. After changing to mozilla, I
had to discover that mailto-links don´t work with external programs. This is
very annoying, because I have to use MSOE 6. I would like to use the mozilla
mailer, but that one doesn´t support various smtp servers for one
profile/user/identity. So, if no one can fix the external mail handler issue,
couldn´t anybody fix the mailer in a way that it worx with multiple mail
accounts same as MSOE? I´ll praise the day i can completely get rid of that MS
>had to discover that mailto-links don´t work with external programs.
That is wrong. I am sure that a google search or reading the mozilla faq will
tell you how.
firstname.lastname@example.org, here are a couple links that you may find interesting:
Guys.. we know there's a workaround. - The bug is here so that we don't need the workaround.
There's no need to post comments on how to do the workaround, we already know how to do that.
In response to #168. There is NO general workaround. There are some in some
cases, but not all configuration have a workaround
what I suggested is not a "workaround", but whatever.
I think we've all heard enough suggestions and workarounds. If you don't have a
proposed patch or are trying to make one then:
Status Whiteboard: DO NOT COMMENT unless you want to help with the
No Comments > Not even to propose that this bug should be addressed as part of
the entire range of missing external executables?
Just which part of "NOT COMMENT unless you want to help with the implementation"
don't you understand...?
*** Bug 205257 has been marked as a duplicate of this bug. ***
*** Bug 183174 has been marked as a duplicate of this bug. ***
*** Bug 208672 has been marked as a duplicate of this bug. ***
*** Bug 210822 has been marked as a duplicate of this bug. ***
It seems that there is a fix for this bug: mozex (mozex.mozdev.org)
I suggest integrating mozex into mozilla as soon as possible, since this is one
of the most important missing features of mozilla.
*** Bug 215650 has been marked as a duplicate of this bug. ***
*** Bug 217028 has been marked as a duplicate of this bug. ***
You also need to move the item about changing E-mail profiles from the EDIT menu
in the main Mozilla application to the PREFERENCES menu. Once I was able to
remove a four-year-old return address, then I no longer needed a separate E-mail
> ------- Additional Comment #88 From email@example.com 2002-05-03 15:38
> if you don't install mailnews then on windows we will farm out mailto: to
> whatever app has registered it.
OK, this bug is one hell of a mountain out of a molehill :-) What needs to
happen is that, at least on Windows and MacOS, Mozilla *always* 'farms out'
mailto: links to the default registered e-mail client. If Mozilla Mail is
installed, it should register itself as the default e-mail client if the user
requests it. Under NO circumstances should Mozilla not use the default
registered mailto: client on these platforms.
On Linux, I'm not sure if there's a default e-mail handler; I'll assume there
isn't. In that case, there ought to be an editbox in preferences specifying the
location of an e-mail handler. I really see absolutely NO need to have a
seperate checkbox, anywhere in prefs, saying 'Use Mozilla Mail'. If the user
wants to use Mozilla Mail, they can damn well register it as the default e-mail
client, or (in Linux) specify its location! There, that simplfies the fix by a
factor of about 1000 ;-)
Now I've been browsing some bugs related to this... I'm not sure whether a fix
providing this kind of functionality has yet been released. All I can say is,
I'm using Mozilla 1.4b (Gecko/20030827) and it's still ignoring my default
registered mail app, and always launching Mozilla Mail for mailto: links. This
bug is so simple to fix I could probably do it, but I will refrain from
submitting a patch as yet as I just can't believe someone hasn't already fixed
this :-) Will wait for version 1.4 and assume it *will* be fixed by then.
CCing self and voting for bug.
eh? what kind of build are you using? we just released 1.5b, i think.
as to the idea that you can just break mozmail that's not acceptable.
imagine someone who installs 3 mail clients and 3 browsers. do you think they'd
be happy if they can only use one of each? why would they have installed all
three of each?
Users have to be able to chose whether they want to use the system default or
some other application.
Sorry, that was a typo; I meant to say I was using Mozilla 1.5b.
> imagine someone who installs 3 mail clients and 3 browsers. do you think they'd
> be happy if they can only use one of each? why would they have installed all
> three of each?
Very good question. Why WOULD they install 3 mail clients? Let's take an
example from earlier in this discussion:
> ------- Additional Comment #55 From jerry asher 2001-12-22 11:54 -------
> I typically have several email accounts, and I actually find it worthwhile to
> have several mail user agents, each configured to a variety of different mail
> For example: I am now trying out Mozilla once more. One day I look forward to
> importing all my email from Eudora into Mozilla, but that's not for today.
> Today, I would like to have Mozilla handle my spam mail account since I
> suspect that Mozilla's security will be better than Eudora's security since
> Eudora uses IE to display html email.
> So I want ALL mailtos to be handled by Eudora.
This confirms my suspicion; that just about anybody with more than one mail
client is always going to want mailto: links to be handled by one client, no
matter where that link was invoked from (Mozilla, IE, an application's "mail the
author" button, etc). The different mail clients on the system are going to be
for different purposes; in this guy's case, Moz Mail for receiving mail from his
spammail account, and Eudora for other accounts and SENDING e-mail.
I see absolutely no circumstance where someone would want different e-mail apps
to be invoked for mailto: links based on what application has invoked that link;
*even when there are multiple mail user agents installed on the system*. If
they do have more than one client, one will be their favorite, under ALL
circumstances, for sending e-mail. That one should be registered as the system
Therefore, I stand by my previous suggestion.
As an aside, how is Mozilla using the default system mail application to handle
mailto links 'breaking' Mozilla Mail? It's still perfectly useable. You just
invoke it manually if it's not your default mail application, or get it to
register itself as default if you want to always send mail with it.
I disagree with the "give the user no choice but to use the Windows shell
mailto: handler" approach. Maybe I'm using an alternate shell that doesn't
support URL handling. More likely, perhaps I want to have different Mozilla
profiles access different mail clients, or invoke the same mail client with
different command-line options to invoke different profiles (one set of profiles
for billable time while working at home, one set for personal). I also doubt
(although I am not certain) that using a native mailto: handler to point to an
external mail website (especially if that site is NOT MSN Hotmail) works, or
that it can be trusted to continue to work in the future. I would think that a
radio choice among "Use system mailto handler", "Use Mozilla Mail" (in the
Seamonkey suite only), and "Use this mailto handler: ", the latter including a
file explorer textbox widget, would be the soundest UI approach. From these,
"Use system mailto handler", if it is defined, would be the sensible default.
Why not just give the user the ultimate choice:
Use System Default or Specify. Under specify, one of the choices would be
"Mozilla/Mail", the other would be "Browse ...", with the ability to specify
command line options, and either the URL or just the email address.
The default for the "Mozilla" distro, would be to use "Mozilla/Mail" like we do
not. Firebird could default to the System default.
This way, everyone is happy. Without this, I don't think we will ever come to a
decision, as people here seem to have VERY strong opinions on how they want it
to work. If we keep bickering, nothing will ever get done.
Just my $0.02
>Use System Default or Specify. Under specify, one of the choices would be
>"Mozilla/Mail", the other would be "Browse ...", with the ability to specify
>command line options, and either the URL or just the email address.
Camino has a nice implementation of this idea for the Home Page pref:
Home Page [ ]
Search Page [ ]
[x] Use system preferences
You can change your system-preferred pages in Internet Preferences
(Open Internet Preferences)
If 'Use system preferences' is checked, the Home Page and Search Page fields are
greyed-out. The radio-button group Paul suggests could behave similarly.
Those last comments are interesting but lack a point which was made clear in the
beginning of the life of this bug :
the "default system mailer" has *no* universal sense. There are configurations
with no notion of "default system mailer".
Gnargh. Can mozilla detect a config where there is no system default? (either
via programmers knowing which systems don't have one or at runtime or a
combination of both or some other means)
If so then we do the following (for example).
For those that have a system default:
[ ] MozMail
[ ] System Default
[ ] _______________________________ [Browse]
And those that do not:
[ ] MozMail
[ ] _______________________________ [Browse]
All that is really needed (AFAICS) is
a. finding a means to detect wether or not we have a system default
b. deciding on the final interface (I just pulled the above outta my ****)
c. finding someone to code it up :)
I think (c) may be the hardest. ;)
> This way, everyone is happy. Without this, I don't think we will ever come to a
> decision, as people here seem to have VERY strong opinions on how they want it
> to work.
Ooh, I'm not sure about that. I'm perfectly happy to have pretty much any
configuration suggested here, and anything as default, just as long as I have
the option to change the setting to my default system mail app.
> Gnargh. Can mozilla detect a config where there is no system default? (either
> via programmers knowing which systems don't have one or at runtime or a
> combination of both or some other means)
Yup. Look at the OS. Windows has a default, Mac (I think) does, Linux/Unix
> If so then we do the following (for example).
> a. finding a means to detect wether or not we have a system default
> b. deciding on the final interface (I just pulled the above outta my ****)
> c. finding someone to code it up :)
That suggestion seems fine, and one which I think pretty much everyone can agree
on. Looks like (a) and (b) are done, I agree that (c) is the hardest but
theoretically it should be pretty easy for a coder with decent Mozilla
experience to whip this up in 5 minutes (alas I don't have that experience :-).
Also BeOS has OS-wide setting since installation for preffered mail-handler
Um. what if my windows system *doesn't* have a default?
Choices should not be based on the os but based on whether the system answers
that there is a system setting.
Lastly, what happens if the user selects use system default for a profile and
the profile runs on a system where there is no system default? Do we pop up the
preferences dialog? Do we pop up a chooser dialog?
None of you are serious about this bug. If your idea of implementations make
sense please, at least have an idea of what systems Mozilla runs on. Describe
each of those systems technique for handling mail and then think logically about
a; eg; How would you find out whether or not the systems have defaults? Is there
an API for such option? If not, then how exactly do you go about detecting?
b; eg; The interface is unimportant until you've finished A
c; eg; No, it can't be whipped up in 5 minutes even if you have "A" completed.
It needs to be tested and the programmer in question would have to have access
to all the platforms in question, he or she would also have to understand each
system and the whole "detect" thing.
I'm tired of reading respones to this bug with poor implementations and off the
cuff analysis. If you're going to respond to this bug be prepared to describe
your implementation especially if you can't patch it yourself. This will make it
easier for others in question to fix this bug so it can finally be closed out.
Please, no more off the cuff analysis, think about your implementation and find
all pieces, then present your idea to others so that they may be able to fix it.
Just a data point for you all:
I'm using FireBird and mozex now. Mozex is an extension that lets you set commands
to run for some protocols and intercepts (some of) the mailto: calls (and some
others, ftp, telnet). It has let me use FireBird and Mozilla without pain for
some time now. I'm a confirmed mutt user so I have it open a terminal with a
suitable mutt composition incantation.
Of course this doesn't solve the problem for non-UNIX platforms, but it certainly
helps a large slab of UNIX users if they're like me: they like the browser (mostly)
but have no desire whatsoever to use the mail component, either because they
hate it or because they already use some perfectly satisfactory mail tool
and see no reason to learn two and to juggle multiple mail stores.
So UNIX people: try mozex and see if this bug becomes a non-issue for you.
*** Bug 218409 has been marked as a duplicate of this bug. ***
*** Bug 219043 has been marked as a duplicate of this bug. ***
*** Bug 219951 has been marked as a duplicate of this bug. ***
*** Bug 221417 has been marked as a duplicate of this bug. ***
This bug should be closed. The howto for mozilla discribes how to use an
external mail prgram, launched from within browser by "mailto" Basically, the
mail application should be de-selected when installing or or updating Mozilla.
The Windows default mail program (ie: Thunderbird) will be launched when mailto
is called up.
That's not a solution/fix. If you are using mozilla mail and you decide that
you want to switch mail client, you would need to reinstall mozilla. You
shouldn't have to do that.
At first I was all towards agreeing that this bug is closed, but I think there
should be some additional work done on it. For one what if users want to use
Netscape Mail as their non-default reader (on demand only) and what if they want
Netscape Mail for their newsgroup reader. Perhaps a right-click over an e-mail
link could allow users to use Netscape Mail vs. their default. There could be a
context menu like:
"Send using Outlook Express (Default Option)"
"Send using Mozilla Mail". There should also be options to uninstall, disable
mail, but not news, and remove from default status Netscape mail from within the
preferences menu. There could also be a way to have and or not have Mozilla
mail default while browsing with Mozilla (ie a non-operating system level
Created attachment 132834 [details]
Screenshot of Opera's mailto: handling preferences
I'm attaching a screenshot of Opera's preferences for handling mailto: links.
(Opera is also a web browser with a built-in e-mail client.) It provides three
- System default
- Specify path
People, don't forget about unix/linux, where there is no system default. There
is currently no way besides mozex to start another mailer from within Mozilla on
unix. And mozex is fine as a technology demo, but its got some UI issues.
*** Bug 221566 has been marked as a duplicate of this bug. ***
I have a need to launch an external email client that is
not my system default client when running firebird with
profiles. I have found on the net the following information
can be added to users.js, for either earlier builds or OS/2
& MAC builds, but they don't seem to work on w2k Mozilla or
Does this belong with this bug or somewhere else?
*** Bug 196720 has been marked as a duplicate of this bug. ***
*** Bug 223186 has been marked as a duplicate of this bug. ***
*** Bug 235796 has been marked as a duplicate of this bug. ***
*** Bug 238787 has been marked as a duplicate of this bug. ***
The workaround described in #72 does not apply for W2K and mail application "The
Bat" and mozilla 1.7b
(In reply to comment #210)
> The workaround described in #72 does not apply for W2K and mail application "The
> Bat" and mozilla 1.7b
There was a change fairly recently that, at least on my computer, makes the
single line in #72 not do the trick. You now also need to specify the mail
Looks like some Internet Config-related breakage; anybody here know in which bug
In Firefox 0.8 this has changed, so that I can set:
network.protocol-handler.app.mailto to "/usr/bin/evolution"
network.protocol-handler.external.mailto to "true"
That configuration syntax seems more rational anyway, and it
also works on a Linux environment for the first time, but I
can't find the related bug.
This also works in Mozilla 1.6 on Linux.
I guess all we need now is a configuration panel other than about:config and
this bug is resolved!
Thats not working for Moz 1.6 on Linux for me. That gives "mailto is not a
registered protocol". Back to mozex for me.
*** Bug 247382 has been marked as a duplicate of this bug. ***
*** Bug 252293 has been marked as a duplicate of this bug. ***
(In reply to comment #199)
> This bug should be closed. The howto for mozilla discribes how to use an
> external mail prgram, launched from within browser by "mailto" Basically, the
> mail application should be de-selected when installing or or updating Mozilla.
> The Windows default mail program (ie: Thunderbird) will be launched when mailto
> is called up.
You're wrong that this issue should be closed. Completely uninstall Mozilla
components is an inapproprate measure for it's inability to correctly launch the
OS's default mail application.
I agree with Rob. As a theme developer I want mail installed but I don't want it
to take precedence over whatever I choose to be my default mail app.
This seems to have changed again in Mozilla 1.7.2 on Fedora Core 2?
In Mozilla 1.7 on Red Hat 9, I was doing this, and it worked:
I have those same settings on my upgraded-to-FC2/1.7.2 system (and about:config
verifies that Mozilla is in fact seeing those values.)
However, when I click on mailto: links, now it launches Evolution instead of
Is there some new preference I need to be setting? I can't tell where my choice
is suddenly getting overridden.
jwz: it's probably honoring your gnome2 settings. there's this registry like
gnome-vfs system which holds them.
> jwz: it's probably honoring your gnome2 settings. there's this registry like
> gnome-vfs system which holds them.
Yeah, apparently recent mozillas unconditionally hand mailto: URLs off to the
"gnome-moz-remote" program, regardless of the "network.protocol-handler" settings.
It turns out that the way to re-fix this is:
- run "gnome-file-types-properties"
- select "Internet Services"
- select "Electronic mail transmission"
- select "Edit"
- replace "evolution" with "gsendmail"
That writes to ~/.gnome/application-info/user.applications something like
It drives me round the bend when people do things like this. I've spent an hour
or two googling to find out how to persuade Firefox to honour mailto URLs and
(1) lots of bad press because Firefox doesn't do it out of the box
(2) possibly you can do it with an extension. This is no use to me because I
want to install it on behalf of hundreds of users, and this is really hard with
(3) various unofficial suggestions for using preferences, which I could not get
(4) Finally I read this response which shows that a developer calmly broke a
user configuration option without changing any documentation
I think that every option in about:config should have an associated comment
defining what the option does. Any deviation from the described behaviour should
automatically be regarded as a bug.
(In reply to comment #220)
> > jwz: it's probably honoring your gnome2 settings. there's this registry like
> > gnome-vfs system which holds them.
> Yeah, apparently recent mozillas unconditionally hand mailto: URLs off to the
> "gnome-moz-remote" program, regardless of the "network.protocol-handler" settings.
> It turns out that the way to re-fix this is:
> - run "gnome-file-types-properties"
> - select "Internet Services"
> - select "Electronic mail transmission"
> - select "Edit"
> - replace "evolution" with "gsendmail"
> That writes to ~/.gnome/application-info/user.applications something like
> command=gsendmail %s
> name=Custom mailto
I would like to see this availible out-of-the-box too, but for now, you can use
WebmailCompose by Jed Brown
which lets you use GMail, Yahoo Mail, Hotmail, Mail.com, Opera, Horde,
SquirrelMail, a custom webmail server, or your default mail editor from a
context menu, or pick your favorite for left-click.
*** Bug 284105 has been marked as a duplicate of this bug. ***
*** Bug 286956 has been marked as a duplicate of this bug. ***
Another solution would be to follow the Windows/IE setting.
That is a non-solution. That's why:
1) It solves anything only on one platform (if at all, see below) while
Mozilla/Thunderbird works on many. Actually this would not even work on Windows
95 as it had no IE version at all.
2) It tries to assume the user actually uses IE (I don't) and knows where to
look for IE settings to control the behavior of mozilla.org software. Silly and
3) It assumes the Windows user has the right IE version. Do you know when IE
introduced this version? Do you know if IE7 (if it is really released) will have
this versions? This makes us too much Microsoft dependant.
Created attachment 184467 [details]
Webmail Compose Extension
Webmail Compose extension for Firefox/Seamonkey, automaticall converts mailto:
links to use preferred webmail site.
(In reply to comment #178)
> It seems that there is a fix for this bug: mozex (mozex.mozdev.org)
> I suggest integrating mozex into mozilla as soon as possible, since this is one
> of the most important missing features of mozilla.
Did this suggestion ever go anywhere? I'm willing to help test for Mac OSX if
this goes somewhere.
*** Bug 304892 has been marked as a duplicate of this bug. ***
Created attachment 245174 [details]
Test Document please ignore
Test attachment document please ignore
*** Bug 330298 has been marked as a duplicate of this bug. ***
My vote too!!!
Problem on windows: This must be handled with the context handler registry stuff and should be possible with firefox.exe in future.
Because there can be mailto:-links in other apps as well that should be handled a "in-Firefox-only" solution is not satisfying!
Forgive me for not reading through the years' worth of comments. I'm not sure if my request/situation would fall under this request, or a new one.
I have some old e-mail in my moz profile, which I don't want to migrate to a new mail client. Therefore, I must install the mail component when I install SeaMonkey (currently 1.1.2).
However, I use web-based e-mail services. Whenever I click on a mailto: link, it sets my clunky XP machine into opening up a composer window, wasting my time, and if I was not expecting it, frustrating me to no end. I'd much appreciate the ability to simply disable mailto: links in SeaMonkey, either in about:config, or with an extension (and to my knowledge, no such extensions exist; I could try webmail compose again, though last time it didn't work for me).
My Send Link does not work anymore? I am unable to send it to people via Gmail as I used to??
Any Help would be Greatly appreciated - Thanks!
I have no problems with this. I added a bookmark to my FF 3 toolbar named "Compose E-mail" whose properties has just the naked "mailto:" keyword as the Location. When I click it, it automatically starts my local Thunderbird to compose a new message. I can then, from the blank message's Tools menu, access any of TB's other screens, and kill the message being composed. Seems to me that the setting for what app. handles the mailto: protocol is, and should remain, in the O/S, not be manipulated by the browser. To give the browser power to do so is a bad idea. It should be handled at the system level. E.g., I guess when TB's installed under Windows, it sets itself as the system default mailto: handler, overriding the default Outlook Express (or whatever is in force), as set in its System Defaults | Default Client db.
There should be an option of some kind to open a Webmail URL, however, as RG wants.
(In reply to comment #236)
> I guess when TB's installed under Windows, it sets itself as the system default
> mailto: handler, overriding the default Outlook Express (or whatever is in
> force), as set in its System Defaults | Default Client db.
> There should be an option of some kind to open a Webmail URL, however, as RG
My opinion on optimum solution is something in the nature of a PrefPane under Browser that allows me to identify the action I want Moz/Sea to take when I click on a mailto: link. Does it open the Moz/Sea email? Thunderbird? Mac Mail? A url in the current window/new tab/new window? Then, users can pick the option they want to use, and forget about it.
I finally built a little Autohotkey-Script thats able to launch the browser with gmail on mailto:
Put this to the registry instead of outlook (or whatever) works systemwide! So this is actually the best way to do it!
put this exe to the registry key : HKEY_CLASSES_ROOT\mailto\shell\open\command
or get Autohotkey and compile by yourself: (works only as exe)
Maybe that works with other webmailclients as well... I don't know. THats gmail only so far. Fine for me :]
Isn't this bug fixed by the existence of user_pref("network.protocol-handler.app.mailto",...) for local apps, and mimetype handlers for urn:scheme:handler:mailto which can include the webmail case?
The GUI to configure these seems adequate too, at least in Debian Iceweasel 3.0.9.
I think this bug can be closed.
Duncan: this bug was originally aimed at the Mozilla suite (it stemmed from something I felt was broken in Netscape Communicator 4.x), and was passed from there to Seamonkey. It's not really a bug against Firefox, so whether it works there shouldn't be the testcase for closing the issue unless the same prefs work properly (without breaking news handling in Composer, or whatever it's called now) in Seamonkey.
Bug 380415 (Implement web-based protocol handlers) implemented all of this bug for both SeaMonkey and Firefox, including the shared backend. For any new issues please file *NEW* bugs. Thanks.
I had a look through the Preferences menu for SeaMonkey 2.4. Am I correct in thinking that, apart from the about:config editor, there's no GUI to edit the network.protocol-handler.external.mailto preference? Have I overlooked it, or should I file a new enhancement request?
If you want to expose this preference to the GUI, you'll need to file a new bug.
Re c241: Philip, can you (or anyone else) confirm that using Seamonkey Composer to post to Usenet works with external.mailto and/or app.mailto turned on? My ISP turned off their NNTP server and I'm not sure if there's a successor to news.netscape.com these days, so I'd be hardpressed to verify it. Even in the early days of the Mozilla Suite, there was a way to redirect mailto: links; my issue at the time was that doing so broke using Composer as a news client; see c240.
Mark, there are a number of open access news servers out there. If you just need one for testing purposes, you could try (for example) nntp.aioe.org. Further information is available at <http://aioe.org/>.
I don't understand Mark Bickford's point. *mailto* has no connection to Usenet, unless you are using a mail to news gateway. Generally Usenet uses NNTP or more rarely UUCP.
Re comment 246 : Agreed. However, when I first made the post that sspitzer used to open this bug (see the bug description), there was an issue in Netscape Communicator such that, if you used the GUI to change the mailto: handler away from Mail/News, Mail/News (IIRC) would then bring up that mail client whenever you tried to reply to a newsgroup. For most standalone SMTP/POP clients, that won't work, hence this bug (the behavior continued at least into the Moz Suite). Sspitzer added the webmail piece when he filed the bug. I am working on verifying if it works properly now.
Thanks Tristan in comment 245 for pointing me to aioe.org. I can report a successful test! Test steps were:
1. Configure news host in Mail/News.
2. Make a successful port to test.post.
3. Turn on the network.protocol-handler.external.mailto pref in about:config.
4. Restart the Seamonkey application, just to be on the safe side.
4. Click a mailto: link, respond to the dialog asking to use my default mailer, verify that a new message window appeared in my mail client.
5. Reopen Mail/News, reload test.post.
6. Click Compose to reply to the group. Old (bad) behavior: a New Message window would be brought up in my mail client. Correct behavior: Mail/News would open its own message composition window.
7. Correct behavior as indicated in Step 6 was observed. I completed the new message to verify that it was in fact posted.
After 12 years, 2 months and a day (although no idea when the underlying issue was actually fixed), and who knows how many organizational and technological changes for the Mozilla project, I think this is done. Are there any older ones still open? :)