35977, 65466, 76237, 88061, 94295, 94777, 121197, 124812, 125932, 134515, 136682, 138513, 140285, 143944, 146218, 150979, 153357, 154582, 155731, 157363, 160263, 160894, 161690, 167273, 170502, 175339, 177136, 181130, 183174, 185114, 188008, 188705, 190570, 195296, 196720, 198631, 205257, 208672, 210822, 215650, 217028, 218409, 219043, 219951, 221417, 221566, 235796, 238787, 252293, 284105, 286956
from "Mark H. Bickford" <firstname.lastname@example.org> "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:email@example.com?cc=foo&subject=bar could become http://firstname.lastname@example.org&cc=foo&subject=bar
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
Summary: [HELP WANTED] mailto: can launch external mail app, or launch a url → mailto: can launch external mail app, or launch a url
Whiteboard: HELP WANTED
Target Milestone: M15
*** 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 up: "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... Gerv
*** 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-... Gerv
Putting on [nsbeta2-] radar. Not on exception feature list.
alt mail is way out there.
Target Milestone: --- → Future
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: list, though... Gerv
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 source.
Yesss.... Big thanks to Big Blue... :)
I have placed the design at: http://www.mozilla.org/ports/os2/selmail/selmail.html 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. Gerv
Marking nsbeta3-. Still a feature, and we're way beyond the point where we're taking new features. Nice idea for the next release.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
*** 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. see http://bugzilla.mozilla.org/show_bug.cgi?id=34819 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. see http://developer.netscape.com/software/sdks/index.html?content=mailnews.html for how this worked in 4.x
19 years ago
*** 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".
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.)
Re: Protozilla 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 postings.
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? Gerv
Re: the above request for an example. Consider: mailto:email@example.com?attach_signature=yes mailto:firstname.lastname@example.orgemail@example.com 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 mailto:firstname.lastname@example.org?set_new_webmail_password=zxcvbnm This is not a new risk; if the user is already logged in to the Web mail account a Web author can just do <a href="http://mailservice.example.com?set_new_webmail_password=zxcvbnm"> 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.
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" functionality.
*** 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.
Assignee: nobody → ducarroz
QA Contact: pmock → sheelar
*** 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. Gerv
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 greatly appreciated.
*** 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 non-mozilla browser".
Summary: mailto: can launch external mail app or launch an url → need option for mailto: to launch external mail app or open a webmail url
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.
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 accounts. 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 external programs... 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. Gerv
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: user_pref("network.protocol-handler.external.mailto", true); 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?
@Prachi Gauriar: 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: http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/unix/nsOSHelperAppService.cpp#1071 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 from Messenger.
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 past 1.0? 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("network.protocol-handler.external.mailto", true); user_pref("applications.mailto", "rxvt -e mutt"); user_pref("applications.mailto.host", "%username%@%host%"); A similar setup should work for any mailer that will take an address as a commandline option.
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]). Cheers.
if you don't install mailnews then on windows we will farm out mailto: to whatever app has registered it.
user_pref("network.protocol-handler.external.mailto", true); 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?
Yuck. 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 certainly necessary.
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". -matt
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) Gecko/20020508 Netscape6/6.2.3 I apologize if this is the wrong place for this, but the problem description matched issue.
*** 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
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
Component: Composition → Preferences
Product: MailNews → Browser
QA Contact: esther → nobody
Target Milestone: Future → ---
*** 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)
Assignee: nobody → ben
QA Contact: nobody → sairuh
When the Mail prefs are canceled out the entire browser crashes in OSX (unexpectedly quits)
*** 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 MacOS.
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 replacement.
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 install...
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.
Whiteboard: DO NOT COMMENT unless you want to help with the implementation
*** 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 this option
*** 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... IE sucks!!! 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. Thank you.
*** 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" messages.... 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 GNOME thing.
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. -M
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 accessed.
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's resolution: - 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 dependency. 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 Sh.. !
>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: http://www.mozilla.org/start/1.0/faq/mail-news.html#3.3 http://bugzilla.mozilla.org/page.cgi?id=etiquette.html Prog.
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 implementation
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 application.
> ------- 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.
Assignee: bugs → nobody
Timeless: 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 > accounts. > 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 default. 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 doesn't. > 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 an implementation. 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 preference).
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 options: - Opera - 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 Firebird. user_pref("applications.mailto","c:\\path\\executable"); user_pref("applications.mailto.parameters","%url%"); 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 application, e.g.: user_pref("network.protocol-handler.external.mailto", true); user_pref("applications.mailto", "/Applications/Mail.app"); Looks like some Internet Config-related breakage; anybody here know in which bug that regressed?
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: user_pref("network.protocol-handler.external.mailto", "true"); user_pref("network.protocol-handler.app.mailto", "gsendmail"); 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 gsendmail. 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 6c8c53b2-1221-43d9-aefa-159a9e77fe94 requires_terminal=false command=gsendmail %s can_open_multiple_files=false name=Custom mailto
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 discovered: (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 extensions (3) various unofficial suggestions for using preferences, which I could not get to work. (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. Bob (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 > > 6c8c53b2-1221-43d9-aefa-159a9e77fe94 > requires_terminal=false > command=gsendmail %s > can_open_multiple_files=false > 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 [https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox&id=206&vid=1088] 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 unproductive. 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.
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. ***
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). Thanks, - RG>
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) <snip> 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. > 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 http://goodsoul.de/_graphics/ahk/webMailTo.exe or get Autohotkey and compile by yourself: (works only as exe) http://goodsoul.de/_graphics/ahk/webMailTo.ahk 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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
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? :)
You need to log in before you can comment on or make changes to this bug.