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)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
seamonkey2.1a1

People

(Reporter: slabbi, Assigned: neil)

References

Details

(Keywords: fixed-seamonkey2.0.1, fixed-seamonkey2.0.3)

Attachments

(2 files, 1 obsolete file)

With renamed variable
2.90 KB, patch
iannbugzilla
: review+
iannbugzilla
: approval-seamonkey2.0.1+
Details | Diff | Splinter Review
Don't use prefs directly
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.
QA Contact: olgam → stephend
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
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.
Component: Mail Window Front End → XP Apps
OS: Windows 2000 → Windows 95
Product: MailNews → Browser
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. ***
OS: Windows 95 → All
Hardware: PC → All
(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
Flags: blocking1.8a5?
bah. The code is all in mailNavigatorOverlay.xul, it just needs to be tweeked.

Patch coming up... if I can remember how to build...
Flags: blocking1.8a5? → blocking1.8a5-
Product: Core → Mozilla Application Suite
Assignee: sspitzer → mail
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
Attached patch Proposed patch (obsolete) — — Splinter Review 
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 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+
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+
Pushed changeset b56cbbc73d87 to comm-central.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 412810 [details] [diff] [review]
With renamed variable

Worth a try, I guess :-)
Attachment #412810 - Flags: approval-seamonkey2.0.1?
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+
Pushed changeset 455177197a6a to releases/comm-1.9.1
Keywords: fixed-seamonkey2.0.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.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: --- → seamonkey2.1a1
(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/*...
Attachment #412207 - Attachment is obsolete: true
(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...
Depends on: 533176
This also fixes --disable-mailnews builds, I guess.
Attachment #416427 - Flags: review?(cbiesinger)
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+
(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.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
(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)?
Attachment #416427 - Flags: approval-seamonkey2.0.2?
Attachment #416427 - Flags: approval-seamonkey2.0.2? → approval-seamonkey2.0.2+
Pushed changeset 7b80393d1152 to releases/comm-1.9.1

(Still without the whitespace change, for consistency.)
Keywords: fixed-seamonkey2.0.2
(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/
Depends on: 534647
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: