Closed
Bug 152526
Opened 22 years ago
Closed 15 years ago
Menu->Send link does not open external mail app (should use mailto:)
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey2.1a1
People
(Reporter: slabbi, Assigned: neil)
References
Details
(Keywords: fixed-seamonkey2.0.1, fixed-seamonkey2.0.3)
Attachments
(2 files, 1 obsolete file)
2.90 KB,
patch
|
iannbugzilla
:
review+
iannbugzilla
:
approval-seamonkey2.0.1+
|
Details | Diff | Splinter Review |
1.21 KB,
patch
|
Biesinger
:
review+
kairo
:
approval-seamonkey2.0.3+
|
Details | Diff | Splinter Review |
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.
Whiteboard: DUPME
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.
Summary: Menu->Send link does not open external mail app → Menu->Send link does not open external mail app (should use mailto:)
Whiteboard: DUPME
*** 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: stephend → benc
Comment 8•21 years ago
|
||
*** Bug 144484 has been marked as a duplicate of this bug. ***
Comment 9•21 years ago
|
||
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.
Comment 10•21 years ago
|
||
I'd imagine the Firebird patch would take little modification to work here.
Component: Mail Window Front End → XP Apps
OS: Windows 2000 → Windows 95
Product: MailNews → Browser
Comment 11•21 years ago
|
||
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.
Comment 12•21 years ago
|
||
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.
Comment 13•21 years ago
|
||
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.
Comment 14•21 years ago
|
||
*** Bug 223186 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
OS: Windows 95 → All
Hardware: PC → All
Comment 15•20 years ago
|
||
(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...
Comment 16•20 years ago
|
||
(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...
Comment 17•20 years ago
|
||
*** Bug 234024 has been marked as a duplicate of this bug. ***
Comment 18•20 years ago
|
||
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.
Assignee | ||
Comment 19•20 years ago
|
||
*** Bug 250788 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
Bug 250788 has a description how this could be implemented
Comment 21•20 years ago
|
||
+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
Flags: blocking1.8a5?
Comment 22•20 years ago
|
||
bah. The code is all in mailNavigatorOverlay.xul, it just needs to be tweeked. Patch coming up... if I can remember how to build...
Updated•20 years ago
|
Flags: blocking1.8a5? → blocking1.8a5-
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•19 years ago
|
Assignee: sspitzer → mail
![]() |
||
Comment 23•15 years ago
|
||
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
Status: NEW → UNCONFIRMED
Assignee | ||
Comment 24•15 years ago
|
||
Seeing as we now always bundle mail, changing the test seems to be best.
Assignee: mail → neil
Status: UNCONFIRMED → ASSIGNED
Attachment #412207 -
Flags: review?(iann_bugzilla)
Comment 25•15 years ago
|
||
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.
Attachment #412207 -
Flags: review?(iann_bugzilla) → review+
Assignee | ||
Comment 26•15 years ago
|
||
I also reversed the way the variable works which cut down on the number of !s.
Attachment #412810 -
Flags: review?(iann_bugzilla)
Attachment #412810 -
Flags: review?(iann_bugzilla) → review+
Assignee | ||
Comment 27•15 years ago
|
||
Pushed changeset b56cbbc73d87 to comm-central.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 28•15 years ago
|
||
Comment on attachment 412810 [details] [diff] [review] With renamed variable Worth a try, I guess :-)
Attachment #412810 -
Flags: approval-seamonkey2.0.1?
Comment 29•15 years ago
|
||
Comment on attachment 412810 [details] [diff] [review] With renamed variable I suppose this a fix rather an enhancement so a=me
Attachment #412810 -
Flags: approval-seamonkey2.0.1? → approval-seamonkey2.0.1+
Assignee | ||
Comment 30•15 years ago
|
||
Pushed changeset 455177197a6a to releases/comm-1.9.1
Keywords: fixed-seamonkey2.0.1
Comment 31•15 years ago
|
||
(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.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: --- → seamonkey2.1a1
Comment 32•15 years ago
|
||
(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/*...
Updated•15 years ago
|
Attachment #412207 -
Attachment is obsolete: true
Assignee | ||
Comment 33•15 years ago
|
||
(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.
Comment 34•15 years ago
|
||
I'll attach a patch to bug 533176 which seems to (help) fix this...
Depends on: 533176
Assignee | ||
Comment 35•15 years ago
|
||
This also fixes --disable-mailnews builds, I guess.
Attachment #416427 -
Flags: review?(cbiesinger)
Comment 36•15 years ago
|
||
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.
Attachment #416427 -
Flags: review?(cbiesinger) → review+
Comment 37•15 years ago
|
||
(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.)
Assignee | ||
Comment 38•15 years ago
|
||
Pushed changeset ede628c2cf8f to comm-central.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 39•15 years ago
|
||
(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 :-(
Comment 40•15 years ago
|
||
(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 :-/
Comment 41•15 years ago
|
||
(In reply to comment #38) > Pushed changeset ede628c2cf8f to comm-central. Can this land on c-1.9.1 (with approval)?
Assignee | ||
Updated•15 years ago
|
Attachment #416427 -
Flags: approval-seamonkey2.0.2?
![]() |
||
Updated•15 years ago
|
Attachment #416427 -
Flags: approval-seamonkey2.0.2? → approval-seamonkey2.0.2+
Assignee | ||
Comment 42•15 years ago
|
||
Pushed changeset 7b80393d1152 to releases/comm-1.9.1 (Still without the whitespace change, for consistency.)
Keywords: fixed-seamonkey2.0.2
Comment 43•15 years ago
|
||
(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?)
Assignee | ||
Comment 44•15 years ago
|
||
(In reply to comment #43) > Is it fixed for you on SM 2.1? Yes, the patch fixes my SM2.1a1pre Linux test box.
Assignee | ||
Comment 45•15 years ago
|
||
Although now that I think about it that was only with the test path of suite/
You need to log in
before you can comment on or make changes to this bug.
Description
•