I use user_pref("network.protocol-handler.external.mailto", true); in my users.js Clicking on a "mailto:" link in the browser and news/mail window opens the external mail app. Unfortunately "Menu->Send link" opens the internal mail app.

I don't think Mozilla has this ability yet. I've seen a bug about this somewhere.

Well add me to the list of people who would like to see this implemented. For the sake of consistency and respecting a user's preferences it just makes sense that any code which calls up the Mail client from the browser should check to see if the user has opted to use an external mail client. I have no desire to migrate my existing email into Mozilla Mail (at this time) and when I send any mail from the browser (including Send Link and Send Page) I want a record of it in my chosen email client's Sent folder.

I don't think this is a dupe. There is one bug that mentions it, but it comes out of the drift of a long bug. This also probably is not a MailNews bug, but a browser-only bug. Chimera (bug 146321) and Phoenix (bug 173954) have looked at this problem.

*** Bug 174285 has been marked as a duplicate of this bug. ***

*** Bug 124417 has been marked as a duplicate of this bug. ***

-> QA to me. I've also searched the entire bugzilla database for "Send page" and "Send link" bugs that complain that it does not work w/ non-MailNews configs, and moved them here. This really is just a browser feature, where you stub the URL into a mailto: URL, and punt it to the OS, not a MailNews feature. For example, if you were to test Chimera or Phoenix, no mailnews QA would participate, but Networking QA would need to test to make sure the mailnews URL is constructed and the mailto: protocol handling is stubbed correctly to the OS. It is also possible that I will take over qa of "network.protocol-handler.external.mailto" eventually as well.

Please get this emplemented soon!

*** Bug 144484 has been marked as a duplicate of this bug. ***

Seth, how hard would this be to fix along with the related Bug 144484 ? Some organizations do not use Mozilla MailNews and are tied to Outlook for one reason or another. Having Send Page/Link use Mozilla Mail can be a major issue for them.

I'd imagine the Firebird patch would take little modification to work here.

Why the change of the OS field from Windows 2000 to Windows 95? The problem also exists on my Windows 2000 machine. Maybe it's not important; I just wondered.

Note that with the fix to bug 144828, the Send Link functionality will use the external mail client IF Mozilla is installed as browser-only (no Mail/News). Send Page to another client (bug 144484) is apparently not feasible. I doubt these are Windows-only bugs, but even if they are there isn't much to be gained by switching the OS from Win2K to Win95. Bugzilla's Platform and OS fields are really not quite up to the task.

For the record, the various windows-blah OS options mean 'the windows OS selected, and every windows OS after it', in the order (IIRC) listed in the combobox. So setting OS = win95 means that it affects 95, and every version of windows below 95, namily windows 95, windows 98, windows ME, windows NT 4.0, windows 2000, and windows XP. So now you know :) Correct me if I'm wrong, the vast majority of supported platforms do not have a mechanism for declaring the OS default mail client. (The only one I can think of besides windows is OSX, and I'm not sure if it does or not). On the other hand, Mozilla should probably be doing by opening a mailto: on every platform, and letting the system handle it where facilities exist.

*** Bug 223186 has been marked as a duplicate of this bug. ***

(In reply to comment #13) > (The only one I can think of > besides windows is OSX, and I'm not sure if it does or not). It does(I'm on Mac OS 10.3), however, as you said, Send Link should just be a mailto link. Is anyone working on patch for this? If not, I'll work on one...

(In reply to comment #13) > (The only one I can think of > besides windows is OSX, and I'm not sure if it does or not). It does(I'm on Mac OS 10.3), however, as you said, Send Link should just be a mailto link. Is anyone working on patch for this? If not, I'll work on one...

*** Bug 234024 has been marked as a duplicate of this bug. ***

RE: Comment 13 For windows: COntrol Panel>>Internet Options>>Programs Tab>>E-Mail Drop-down box, select <<Your Program Here> be it TB, or OE, or the Moz built-in.

*** Bug 250788 has been marked as a duplicate of this bug. ***

Bug 250788 has a description how this could be implemented

+mscott. Promoting thunderbird is a good thing for mozilla, so I'd like to put this up for consideration. stop me if I'm wrong, but w/ the powers of lxr, I found the menu command lives at: http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/mailNavigatorOverlay.xul#106 And in firefox, the code is here: http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.js#4830

bah. The code is all in mailNavigatorOverlay.xul, it just needs to be tweeked. Patch coming up... if I can remember how to build...

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Seeing as we now always bundle mail, changing the test seems to be best.

Comment on attachment 412207 [details] [diff] [review] Proposed patch The variable name is no longer correct with this change, so should be renamed - perhaps gUseIntegratedMailClient? r=me with that fixed.

I also reversed the way the variable works which cut down on the number of !s.

Pushed changeset b56cbbc73d87 to comm-central.

Comment on attachment 412810 [details] [diff] [review] With renamed variable Worth a try, I guess :-)

Comment on attachment 412810 [details] [diff] [review] With renamed variable I suppose this a fix rather an enhancement so a=me

Pushed changeset 455177197a6a to releases/comm-1.9.1

(In reply to comment #30) > Pushed changeset 455177197a6a to releases/comm-1.9.1 http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey2.0&maxdate=1259205362&hours=12 This changeset caused [ TEST-PASS | chrome://mochikit/content/browser/suite/smile/test/browser_ApplicationPrefs.js | A single preference should not be locked. TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/suite/smile/test/browser_ApplicationPrefs.js | Timed out ] on all platforms. Regression timeframe: http://hg.mozilla.org/releases/comm-1.9.1/pushloghtml?fromchange=39add317ae93&tochange=455177197a6a (I don't know about SM 2.1.)

(In reply to comment #31) > TEST-UNEXPECTED-FAIL | > chrome://mochikit/content/browser/suite/smile/test/browser_ApplicationPrefs.js > | Timed out Doesn't time out when running alone or /suite/smile/*, times out (with no (error) console output) when running /suite/*...

(In reply to comment #32) > (In reply to comment #31) > > TEST-UNEXPECTED-FAIL | > > chrome://mochikit/content/browser/suite/smile/test/browser_ApplicationPrefs.js > > | Timed out > Doesn't time out when running alone or /suite/smile/*, > times out (with no (error) console output) when running /suite/*... I can confirm that this is somehow due to the use of Application.prefs in mailNavigatorOverlay.xul; if I switch that to a normal pref branch then the tests pass.

I'll attach a patch to bug 533176 which seems to (help) fix this...

This also fixes --disable-mailnews builds, I guess.

Comment on attachment 416427 [details] [diff] [review] Don't use prefs directly + .getProtocolHandler("mailto") + instanceof Components.interfaces.nsIExternalProtocolHandler; I think this indentation is somewhat misleading, since it makes it look like instanceof is a continuation of the previous expression. I'd probably indent it to the same level as "Components", but feel free to go with whatever you prefer.

(In reply to comment #34) > I'll attach a patch to bug 533176 which seems to (help) fix this... Ftr, that patch did "fix" this failure on Windows (though I've no idea why), but did not on Linux: hopefully, your patch will. (MacOSX has not completed yet.)

Pushed changeset ede628c2cf8f to comm-central.

(In reply to comment #36) >(From update of attachment 416427 [details] [diff] [review]) >>+ .getProtocolHandler("mailto") >>+ instanceof Components.interfaces.nsIExternalProtocolHandler; >I think this indentation is somewhat misleading, since it makes it look like >instanceof is a continuation of the previous expression. I'd probably indent it >to the same level as "Components", but feel free to go with whatever you >prefer. Sorry, I forgot to address this :-(

(In reply to comment #37) > (In reply to comment #34) > > I'll attach a patch to bug 533176 which seems to (help) fix this... > > Ftr, that patch did "fix" this failure on Windows (though I've no idea why), > but did not on Linux: hopefully, your patch will. > (MacOSX has not completed yet.) Actually, (MacOSX is still orange and) Windows changed from perma-orange to random-orange only :-/

(In reply to comment #38) > Pushed changeset ede628c2cf8f to comm-central. Can this land on c-1.9.1 (with approval)?

Pushed changeset 7b80393d1152 to releases/comm-1.9.1 (Still without the whitespace change, for consistency.)

(In reply to comment #42) > Pushed changeset 7b80393d1152 to releases/comm-1.9.1 Well, that didn't fix it either on SM 2.0 :-/ (Is it fixed for you on SM 2.1?)

(In reply to comment #43) > Is it fixed for you on SM 2.1? Yes, the patch fixes my SM2.1a1pre Linux test box.

Although now that I think about it that was only with the test path of suite/