Menu->Send link does not open external mail app (should use mailto:)

RESOLVED FIXED in seamonkey2.1a1

Status

SeaMonkey
UI Design
RESOLVED FIXED
15 years ago
8 years ago

People

(Reporter: Stephan Slabihoud, Assigned: neil@parkwaycc.co.uk)

Tracking

({fixed-seamonkey2.0.1, fixed-seamonkey2.0.3})

Trunk
seamonkey2.1a1
fixed-seamonkey2.0.1, fixed-seamonkey2.0.3
Dependency tree / graph
Bug Flags:
blocking1.8a5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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.

Comment 1

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

Comment 2

15 years ago
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.

Updated

15 years ago
QA Contact: olgam → stephend
Whiteboard: DUPME

Comment 3

15 years ago
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

Comment 4

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

Comment 5

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

Comment 6

15 years ago
-> 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 7

15 years ago
Please get this emplemented soon!

Comment 8

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

Comment 9

14 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

14 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

14 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

14 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

14 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

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

Updated

14 years ago
OS: Windows 95 → All
Hardware: PC → All

Comment 15

13 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

13 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

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

Comment 18

13 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

13 years ago
*** Bug 250788 has been marked as a duplicate of this bug. ***
Bug 250788 has a description how this could be implemented

Comment 21

13 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

13 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

13 years ago
Flags: blocking1.8a5? → blocking1.8a5-
Product: Core → Mozilla Application Suite

Updated

12 years ago
Assignee: sspitzer → mail

Comment 23

8 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

8 years ago
Created attachment 412207 [details] [diff] [review]
Proposed patch

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

8 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

8 years ago
Created attachment 412810 [details] [diff] [review]
With renamed variable

I also reversed the way the variable works which cut down on the number of !s.
Attachment #412810 - Flags: review?(iann_bugzilla)

Updated

8 years ago
Attachment #412810 - Flags: review?(iann_bugzilla) → review+
(Assignee)

Comment 27

8 years ago
Pushed changeset b56cbbc73d87 to comm-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 28

8 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

8 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

8 years ago
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
(Assignee)

Comment 33

8 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.
I'll attach a patch to bug 533176 which seems to (help) fix this...
Depends on: 533176
(Assignee)

Comment 35

8 years ago
Created attachment 416427 [details] [diff] [review]
Don't use prefs directly

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.)
(Assignee)

Comment 38

8 years ago
Pushed changeset ede628c2cf8f to comm-central.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 39

8 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 :-(
(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)?
(Assignee)

Updated

8 years ago
Attachment #416427 - Flags: approval-seamonkey2.0.2?

Updated

8 years ago
Attachment #416427 - Flags: approval-seamonkey2.0.2? → approval-seamonkey2.0.2+
(Assignee)

Comment 42

8 years ago
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?)
(Assignee)

Comment 44

8 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

8 years ago
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.