Closed Bug 144828 Opened 22 years ago Closed 21 years ago

mailto: does not open default mail client, nav only doesn't have File | Send ... and File | New | Message UI.

Categories

(MailNews Core :: Networking: SMTP, defect)

Product:
MailNews Core
Component:
Networking: SMTP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4alpha

People

(Reporter: gregg, Assigned: shliang)

References

(
URL
)

Details

(Whiteboard: [adt2])

Attachments

(2 files, 1 obsolete file)

patch
23.30 KB, patch
jag+mozilla
: review+
sspitzer
: superreview+
sspitzer
: approval1.4b+
Details | Diff | Splinter Review
additional patch
2.66 KB, patch
sspitzer
: superreview+
sspitzer
: superreview+
sspitzer
: approval1.4+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    2002051006

GroupWise is my default email client, and I have modified my user.js file to
include:
user_pref("network.protocol-handler.external.mailto", true);

When I click on a mailto: link in Mozilla, nothing happens (mail and news
components of Mozilla are not installed). When I click on a mailto link in IE,
GroupWise opens (as expected).

Reproducible: Always
Steps to Reproduce:
1.Start Mozilla
2.Click on mailto: link


Actual Results:  Nothing happens

Expected Results:  Mozilla should have opened my default email client, like IE does.

I'm tagging this as a major bug, because in order for a good argument to be made
to move away from other browsers, there needs to be support for basic features,
such as allowing me to choose my own email client, and not being forced to use
the Mozilla email application.
WFM [Mozilla 2002051306 (1.0 branch), Windows 2000, Pegasus Mail 4.01], with
Pegasus already installed, from a completely fresh install of Mozilla without
Mail & Newsgroups, and no PREFS.JS or USER.JS settings changed
Still does not work for me [Mozilla 2002052108 (1.0 branch), Windows NT4sp6,
GroupWise 6.0], with GroupWise already installed, from a completely fresh
install of Mozilla without Mail & Newsgroups, and no PREFS.JS or USER.JS
settings changed.

Also tried with the previously mentioned user.js setting changed, still no luck.

Tested on three different systems, of the same config.
Severity: major → critical
This is a new bug. It did not exist in the build I was using previously, which
was from sometime in the middle of April 2002.

*** This bug has been marked as a duplicate of 137795 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
sorry. not a dup
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I see this in Mozilla 1.0 with Eudora 4.3.2 in Windows 2000.

Clicking on a mailto brings up Mozilla Mail thank you very much instead of my
default mailer, Eudora.  In IE, I get Eudora.

I know I've reported this before with prior versions, but damn bugzilla, I can
never find anything with this system.
Same bug here, I have an error message stating that no mail conduit is 
available (or something like that). Seems that it works with retail 1.0 but not 
with the trunk (I'm using 2002061707 right now)

I'm running win2k
This should definitely be confirmed. I have the same problem with Eudora as my
default mailer. This is a very bad problem. Whenever I want to mail someone a
web page, a very common thing to do, I have to open it in IE.

Simple MAPI is only responsible for setting the Windows registry settings to
make Mozilla the default mailto handler when the user makes Mozilla as the
default mail application. 

The code that handles mailto and brings up the Compose Window when the user
clicks a mailto URL in Mozilla is the mailto handler (nsMailtoUrl) part of the
Smtp code.

Changing the component to SMTP.
Component: Simple MAPI → Networking: SMTP

*** This bug has been marked as a duplicate of 56478 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Why is this a duplicate of 56478 "Clicking on a mailto: link doesn't bring up a
mail client if Mozilla is installed without Mail/News"? In comments 5 and 8 (at
least) Mozilla Mail/News is definitely installed.
This is not a duplicate of bug 56478. Bug 56478 is clearly filed under the OS
category of Linux, nowhere in my original bug report did I indicate I was using
Linux...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
This bug is also reproducible on Mac OS. Platform should be something other than PC?
Is this a dup of bug 11459, or is it a regression in the pref
user_pref("network.protocol-handler.external.mailto", true); ?
Evelyn - Here is one of those bugs we were talking about...There is a similar
one that is very close to a dup of this one
(http://bugzilla.mozilla.org/show_bug.cgi?id=144828)

We need to have this fixed for Buffy.  Nominating nsbeta1.
Keywords: nsbeta1
ccing Scott - he and I spoke today
reassigning to sspitzer.
Assignee: rdayal → sspitzer
Status: REOPENED → NEW
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
I'm using MS Outlook 2002, and it's dumping me into Mozilla Mail as well.  
This is definitely a must-fix.  In fact it's been bothering me for quite a 
while... :-)
According to the FAQ at 
http://www.mozilla.org/start/1.0/faq/mail-news.html#3.3 , you can just say 
this in user.js:

user_pref("network.protocol-handler.external.mailto", true);

Does that mean fixing this bug on Mac and Windows is as easy as 
changing the default preference from false to true?
According to my original report, I already tried this switch. It does not work... 
Here, reproducible always.
Mozilla is the default browser
OExpress is the default Mail Program.

Any mailto: link within mozilla will opoen up the composer window, instead of
(as it should) the Oexpress window.
For those seeing this: what is the value of the windows registry keys
[HKEY_CLASSES_ROOT\mailto\shell\open\command] and
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command]?
"C:\PROGRA~1\MICROS~3\Office10\OUTLOOK.EXE" -c IPM.Note /m "%1"

That's my command.  All programs, including phoenix properly handle this. 
Mozilla does not, and unconditionally launches its own mailer.
An other thing to check; does the line
user_pref("network.protocol-handler.external.mailto", true); get copied into
prefs.js? This should happen when you quit mozilla the first time after this
line is added to user.js.
After adding this entry to my prefs.js manually, Mozilla does what it is
supposed to.  However, I find it strange that Mozilla did not do this on its own....
So, the problem seems to be that mozilla does not read user.js. Kevin, could you
try to add other lines to user.js to check that nothing get transfered to
prefs.js? Note that you have to start and shutdown mozilla before the content of
user.js get copied to prefs.js.
Just one more thing to check, make sure you have set up windows to show the
extension to all files and that the file is named user.js and not user.js.txt
Have the same problem, fixed with the hint from comment #19.
Mozilla 1.2, default mailer Outlook (XP).

This is still a bug though (IMHO) as the tick in Preferences->Mail&Newsgroups
should do the trick by itself.
There is no UI for this setting, that is bug 11459. 

Is anyone with a correctly named user.js still seeing this?
*** Bug 183174 has been marked as a duplicate of this bug. ***
->all; also see this on Mac OS X (eg, where Mail.app is the default mail client).
OS: Windows NT → All
Hardware: PC → All
sairuh, are you seeing this yourself? I really think this is due to incorrectly
named user.js, which can be hard to see since windows (and Mac OS X IIRC) hides
some extensions.
WORKSFORME using user.js on 2002120103/MacOS 9.2.2 + Outlook Express
and 2002112907-MachO/MacOS 10.2.1 + Mail.app.
I agree with comment 32.
ah, i'll check that out in a bit...
WFM with user.js with build 2002120908/WIN2K SP3.  I think this is a significant
enough issue that it ought to be in the release notes.  I would be willing to
write up the issue for inclusion, but I need to be pointed in the right
direction for who to send it so and for format/style guidance.
Still does not work for me; NT4sp6, Mozilla 1.2.1 (20021130). I've also tried
manually adding the below mentioned line to my user.js file with no success:
 user_pref("network.protocol-handler.external.mailto", true);

I've noticed that once the above setting has been added to my user.js file, this
setting is automatically added to my prefs.js file after starting and closing
Mozilla.

In addition, I've double-checked these filenames from a dos window, in order to
be absolutely sure they are named correctly.

Output of DOS/cmd "dir" command:
 Volume in drive C is Local_Drive
 Volume Serial Number is XXXX-XXXX

 Directory of C:\WINNT\Profiles\testuser\Application
Data\Mozilla\Profiles\Test\6oygcjhe.slt

12/10/02  09:50a        <DIR>          .
12/10/02  09:50a        <DIR>          ..
12/10/02  09:48a                 5,323 bookmarks.html
12/10/02  09:44a        <DIR>          Cache
12/10/02  09:44a        <DIR>          chrome
12/10/02  09:50a                   765 history.dat
12/10/02  09:48a                 6,055 localstore.rdf
02/01/02  04:07p                   298 mimeTypes.rdf
11/24/02  07:51a                 1,647 panels.rdf
12/10/02  09:50a                     0 parent.lock
12/10/02  09:47a                   730 prefs.bak
12/10/02  09:48a                   792 prefs.js
11/24/02  07:51a                 2,071 search.rdf
12/10/02  09:47a                    64 user.js
12/10/02  09:48a             1,202,643 XUL.mfl
              15 File(s)      1,220,388 bytes
                             87,099,392 bytes free

To answer comment 22:
 The registry values:
 [HKEY_CLASSES_ROOT\mailto\shell\open\command]
   (Default)=C:\Novell\GroupWise\gwmailto.exe /%
 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command]
   (Default)=C:\Novell\GroupWise\gwmailto.exe /%
  

Gregg, can you try to install Mozilla _without_ mailnews and report back what
happens when you click on a mailto link.
And just to be sure, you have tried to create a new profile?
Actually, I had already done both at the time of my last reply. I first
uninstalled Mozilla, then reinstalled 1.2.1, then deleted my existing profile,
and used the profile manager to create another one. Now that I think about it;
the only thing I didnt do, was delete the c:\program files\mozilla directory
structure before reinstalling (just to be sure everything was deleted during the
uninstall) I can try that...
Editing prefs.js doesn't work for me.
QA Contact: trix → stephend
Mail triage team: nsbeta1+/adt2
Whiteboard: [adt1] → [adt2]
I to have this problem, with one wrinkle. After editing my pref.js file (I do 
not have a user.js file) to include:

user_pref("network.protocol-handler.external.mailto", true);

When I click on a mailto: link my Eudora comes up (my default mail client).  
HOWEVER when I use File -> Send Page, N7 mail client pops up, disregarding my 
registry and Internet Options settings.  I am running WinNT4.0 sp 6 as well.
Today I installed the entire set up on a Win98 box and can duplicate the issue.
 Clicking on a mailto link will bring up Eudora, using File -> Send Page will
not.  It seems as if the issue is not WinNT related.
see also http://www.mozilla.org/mailnews/altmail/index.html

accepting, I hope to get to this for 1.3 final, as it's important nav only users.
Status: NEW → ASSIGNED
i have a similar problem but the other way round. i have mozilla as my default
mail and browser. when i use explorer on a mailto link, netscape 4.61 (which was
my primary before mozilla) starts up, and net shows an own mail composing
window. it only works properly in mozilla itself. 
updating summary, aiming for 1.3 final
Summary: mailto: does not open default mail client → mailto: does not open default mail client, nav only doesn't have File | Send ... and File | New | Message UI.
Target Milestone: --- → mozilla1.3final
not going to happen for 1.3 final.

now hoping for 1.4 alpha.
Target Milestone: mozilla1.3final → mozilla1.4alpha
(fixed URL)

If this bug has morphed from "mailto:" didn't work right for me to "File | Send
<stuff>" does not use "network.protocol-handler.external.mailto", that should
really be a new bug.

As for editing prefs, I've put up some documentation on prefs, I'd be looking
for some feedback, and hopefully it will help other people who want to change
this setting (I already learned a couple things about user.js, I've alwyas been
a prefs.js hacker)...

http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html
URL: http://mailto: → mailto:
> If this bug has morphed from "mailto:" didn't work right for me to "File|Send
> <stuff>" does not use "network.protocol-handler.external.mailto", that should
> really be a new bug.

There is one already (Don Catanzaro, please take note): Bug 152526.

I've been working out the mailto issue today, testing Mozilla 1.3 final on
Windows 2000 SP3, plus some similar testing on a Win98SE laptop.

1) The protocol-handler.external pref *was* copied from user.js to prefs.js.
I did have a glitch there where I put the "true" in quotes, interpreted as
a string; once stored in prefs.js like that, an unquoted version in user.js
did not override the prefs.js one; I had to edit prefs.js to fix it.

2) In every case where HKEY_CLASSES_ROOT\mailto\... pointed to an executable
*and* the protocol-handler.external.mailto pref was true, Mozilla opened the
correct program.  I could not duplicate the problems described in Comment 36.
Following up myself: I am not sure that this bug should be left open, at least
without additional information from reporters.  I have no problems getting
Mozilla to open a different program under Windows, and I understand from
extensive reading of other mail-related bugs that the net.p-h.ext.mailto pref
works for OSX as well.  The same issue under Linux is addressed by Bug 56478.

One issue that might be addressed by this bug is whether the preference should
have a UI associated with it; and, see also Bug 196798.

Windows users who are still seeing this problem: check to be sure that you have
a program associated with 'mailto' in the Windows registry.  
 -- Win98: In Windows Explorer, open View|Folder Options.  Select the File
Types tab.  Scroll down to find the entry for "URL(mailto)" (near the bottom
of the list); click Edit; select the "open" action; click Edit.
 -- Win2K: In Windows Explorer, open Tools|Folder Options.  Select the File
Types tab.  Scroll down to find the entry "N/A -- URL(mailto)"; click
Advanced; select the "open" action; click Edit.

Alternately, in the Registry Editor, locate
   HKEY_CLASSES_ROOT\mailto\shell\open\command
and see what the 'default' value for that key is.

Since I want Mozilla as my default mailer, I have this value set to
  "C:\Program Files\Mozilla\mozilla.exe" -mail "%1"

The precise syntax of that command for other mailers is dependent on those
programs.  I know from testing that Outlook Express will set up this key
correctly for itself.  (Mozilla does *not* set this key up when it declares
itself the default mailer, for which see Bug 96717.)
In regards to comment #49, I am still seeing this with Mozilla 1.3
(Gecko/20030312) on NT4sp6a. Mail/News is not installed, and my registry entry
still shows the same values as noted in comment #36. The prefs.js/user.js entry
is as follows:
 user_pref("network.protocol-handler.external.mailto", true);

It looks like comments #45 and #46 hint towards a fix in a later Mozilla
milestone release...
ok, I think we just care about:

handling mailto: properly

and:

File | New Message
File | Send Page 
File | Send Link

and the context menu stuff. (see mailNavigatorOverlay.xul) when mail is not
installed.  (build --disable-mailnews)

once we get the front end work done, we'll figure out how to properly launch the
default mailer, which will be fun.  

(blizzard already has some ideas for linux.)
Assignee: sspitzer → shliang
Status: ASSIGNED → NEW
The usual way to do this is to just pass the url to be loaded to a command line
handler that knows how to find the right browser and launch it if required.  

There's also the internal route where you can use the xremoteservice to talk to
an already running instance. (mozilla -remote already uses this.)  Then you can
launch something if it's not running.

On recent Red Hat versions we just have a little program called htmlview that
passes urls to the "right" browser.
Attached patch preliminary patch (obsolete) — — Splinter Review 
add file|new msg and send link, send image in context menu to nav-only installs
Attachment #122148 - Flags: review?(sspitzer)
Comment on attachment 122148 [details] [diff] [review]
preliminary patch

1)

+    var gCanCompose = ("@mozilla.org/messengercompose/composeparams;1" in
Components.classes);

instead of gCanCompose, something like gHaveIntegratedMailClient;

2)

+<!ENTITY  newMessageCmd.label		   "Message">
+<!ENTITY  newMessageCmd.accesskey	   "m">

should be "M", right?

3)

+<!ENTITY  newCardCmd.label		   "Address Book Card...">
+<!ENTITY  newCardCmd.accesskey 	   "c">

should be "C", right?
Attachment #122148 - Flags: review?(sspitzer)
Attached patch patch — — Splinter Review 

        Attachment #122148 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 122234 [details] [diff] [review]
patch

sr/a=sspitzer

        Attachment #122234 -
        Flags: superreview+

        Attachment #122234 -
        Flags: approval1.4b+

    
    

    
  
Comment on attachment 122234 [details] [diff] [review]
patch

r=jag

        Attachment #122234 -
        Flags: review+

    
    

    
  
As part of the Nav-only install issue, shouldn't the preference for
  network.protocol-handler.extern.mailto
be set to True by default?  (per Bug 196798)

    
    

    
  
patch checked in
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED

    
    

    
  
It's a shame that we did cvs remove and cvs adds here and lost revision history.

    
    

    
  
> It's a shame that we did cvs remove and cvs adds here and lost revision history.

leaf might be able to fix that, by hand.

    
    

    
  
> As part of the Nav-only install issue, shouldn't the preference for
> network.protocol-handler.extern.mailto
> be set to True by default?  (per Bug 196798)

is that needed?  I saw shuehan run her fix on windows, 
and I don't think she had that.

but if that's the case, maybe we can do is this:

at build time, if we are building --disable-mailnews, 
in mozilla/modules/libpref/src/init, add a disable-mailnews.js that *only* gets
built / installed when we don't build mailnews.  

network.protocol-handler.extern.mailto can be set to true in disable-mailnews.js.

note, for nav only installs, we have (and need) mailnews.js.  
(shuehan, can you confirm?)

the reason is for people who do this:

1)  run 4.x (with mail)
2)  install mozilla, just the browser
3)  migrate the 4.x profile (need mailnews.js to migrate properly)
4)  later, install mozilla again, with mail

obviously, if you don't build --disable-mailnews, we don't want to export
disable-mailnews.js

    
    

    
  
logged bug #204621 for better linux support, per blizzard.

I'm not sure if mac works well or not.

    
    

    
  
>> As part of the Nav-only install issue, shouldn't the preference for
>> network.protocol-handler.extern.mailto
>> be set to True by default?  (per Bug 196798)
> is that needed?  I saw shuehan run her fix on windows, 
> and I don't think she had that.

I am having a lot of trouble getting the 0506 build to behave (due to Bug 
204676), but the testing I was able to do indicates that this preference now 
makes no difference (Windows 98).

It appears that in a Navigator-only installation (Messenger not installed), the 
system mailer will be used for the menu items and for mailto: links; this is as 
desired and maybe even will fix the problem for the original reporter, who had 
no luck using the preference to get the browser to handle mailto:'s with his 
default mail program.  You could claim that this fix has also fixed Bug 152526.

In a Navigator-plus-Messenger installation, it appears that Messenger will be 
used for all invocations of the mailer from the browser, even if Messenger is 
not the default mail program.  For those who want to have an alternate primary 
mailing program, but also to keep Messenger installed for testing or whatever 
reason, this could be a problem.

    
    

    
  
Does mailto: not support &subject= for the send page/image title?

    
    

    
  
Neil:  mailto:?subject=  works fine (for invoking Messenger, Win2K); using the 
menu items, the subject is not set for Send Image (image context menu), but it 
is set for Send Page or Send Link (from the File menu) or Send Page (from the 
page context menu) -- again, for invoking Messenger.

For an external mailer, the subject is not being set; and for Send Image, the 
image is not being attached.  I don't think the page is being attached for Send 
Page, either, but I've got another problem right now where I can't verify that. 
It's possible the problem of "no attachment" is a problem with the mailer I'm 
using to test; is there a generic means of specifying an attachment when 
invoking a mail program?  If not, maybe the Send Page and Send Image menu items 
should *not* be included for non-Messenger mail installations.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        additional patch
        — 
          — Splinter Review
      

    


  
add subject to mailto, fix js errors in message view source, forgot to check in
contents.rdf

    
  

        Attachment #122680 -
        Flags: superreview?(sspitzer)

    
    

    
  
Comment on attachment 122680 [details] [diff] [review]
additional patch

r/sr/a=sspitzer for 1.4 final. (the tree should be open for that soon.)

        Attachment #122680 -
        Flags: superreview?(sspitzer)

        Attachment #122680 -
        Flags: superreview+

        Attachment #122680 -
        Flags: approval1.4+

    
    

    
  
I am now using the 050712 build, which fixed the problem that was interefering 
with my testing.  I am not seeing   Send Page   menu items in either the context 
menu or the File menu, in a Navigator-only installation (Win98); I'm not sure, 
now, if they were available in 0506.   File|New|Message, File|Send Link  and  
Send Image (from the image context menu) are all present; the latter two behave 
as described in comment 66.

    
    

    
  
shuehan, could this fix have caused bug #204882?

    
    

    
  
additional patch checked in

    
    

    
  
> I am not seeing  Send Page menu items in either the context 
> menu or the File menu, in a Navigator-only installation (Win98)

send page isn't implemented, because we don't have a way to send the page to the
external mailer. 

    
    

    
  
That makes sense; in that case, don't you also need to remove Send Image from 
the image context menu (as I suggested in comment 66)?

    
    

    
  
send image will act like send link in that case, and send a link to the image

    
    

    
  
Using trunk build 20030515 on winxp I installed ns7 without mail component and
launched Browser then tested these cases and they have passed:

1.) Outlook 2000 set as default mail app
Send Link, Send Image and mailto link  brought up Outlook compose window. Sent
msg = received it.

2.) Outlook Express set as default mail app
Send Link, Send Image and mailto link  brought up Outlook Express compose
window.  Sent msg = received it.

3.) Eudora Pro set as default mail app
Send Link, Send Image and mailto link brought up Eudora Pro compose window.
Sent message = received it.

4.) Migrated a 4.7 profile that had a mail account set up.
Send Link, Sent Image and mailto link still brought up Eudora Pro compose window
which is OK because NS7 doesn't have the mail component installed.

5.) Installed ns7 with mail component and ran migrated profile from step 4
(answered yes to make mail default. Send Page, Send Link and mail to launched
ns7 mail compose window.   Mail component functioned correctly.  Exit.

6.) Reset Eudora as default mail client and launched ns7 without mail client.
Send Link, Sent Image and mailto link still brought up Eudora Pro compose window.  

I tested this on winxp only all scenarios passed.  
Those reporting scenarios in this bug using other mail apps as default and other
OS's  please test your scenarios again with fixed build and update this bug.  
 

    
    

    
  
Since my testing of this bug shows it working and I have no response from others
who saw this probem, I will verify it as fixed.  If there is a scenario that
still does not work, please reopen and give specific steps and OS. 
Status: RESOLVED → VERIFIED

    
    

    
  
The bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=183174">183174</a>
marked as duplicate of this one still be valid: how to use an other mail client
than Mozilla when following the 'mailto' links.

    
    

    
  
Re comment 78: that is because bug 183174 really is a dupe of bug 11459.
Product: MailNews → Core
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: