Closed Bug 144828 Opened 23 years ago Closed 22 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: 23 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: 23 years ago → 23 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: 23 years ago → 22 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: