Closed Bug 207974 Opened 21 years ago Closed 21 years ago

mailto: in start/run will start Outlook Express instead of Mozilla Mail

Categories

(MailNews Core :: Simple MAPI, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 202497

People

(Reporter: werner.bruhin, Assigned: cavin)

References

(Depends on 1 open bug)

Details

Attachments

(2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425

Some application use mailto: to start the default e-mail application.  Mozilla
mail does not update the registry entry for 

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto

even so I selected in Preferences/mail & newsgroup - use Mozilla as the default
mail application

Reproducible: Always

Steps to Reproduce:
1. select start menu
2. select run
3. enter "mailto:" and press OK

Actual Results:  
Outlook Express starts instead of Mozilla mail

Expected Results:  
Update the windows registry mentioned under details when selecting mozilla as
the default mail application.
I can confirm that this happens. The key in question is not updated. On my
machine, it opens a window in Outlook, which was the default email program
before Mozilla Mail. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/2003060608
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a more general problem.
In fact, setting Mozilla Mail as the default mail client doesn't set it for
ANYthing in windows, other than Mozilla itself. I've tried mailto links from IE,
from Word, and from mIRC: all open in Outlook (my default program.
This key
HKEY_CLASSES_ROOT\mailto\shell\open\command

Should be updated from whatever it is to:

C:\PROGRA~1\MOZILLA.ORG\Mozilla\mozilla.exe -mail "%1"

Of course, the exe should be wherever mozilla.exe is.
The error is in
http://lxr.mozilla.org/mozilla/source/mailnews/mapi/mapihook/src/nsMapiRegistryUtils.cpp#522
It reads
522             keyName.Append("\\protocols\\mailto");

It should read
522             keyName.Append("\\Classes\\mailto");

If I can figure out how to write a patch, I will. :)
Attached patch A possible fix (obsolete) — Splinter Review
It appears that this is the only key here that is explicitly wrong. If you
check the default value in windows, this is the key that is changed. There is
no protocols key here, Only classes.

I don't have the ability to build, so I have NOT tested this patch. But I do
know that this is the key that needs to be updated to set mozilla as default
mail for mailto: in windows.
This problem should NOT be fixed until we fix 209328. Otherwise, we'll break
mailto for all of windows, and not just mozilla.

Also, is it possible that the key name was changed from win 9x to win2k or
winxp? I would like to see some input from win9x and win2k users.
Depends on: 209328
Keywords: qawanted
I have access to W98, W2K and an XP machine, so checked the registry on all
three and here are my findings:

HKEY_CLASSES_ROOT\CSLID
HKEY_CLASSES_ROOT\mailto
HKEY_CLASSES_ROOT\PROTOCOLS\Handler\mailto

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CSLID
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler\mailto

These are (at least I believe, i.e. I am NOT a registry expert) the relevant
entries AND THEY ARE ALL THE SAME ON W98, W2K, and XP.

On my 98 machine I did a little test and switched default mail to Corel's e-mail
 (which was the only other one I had on there) and it changed the following two:

HKEY_CLASSES_ROOT\mailto
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto

Hope this helps and thanks for looking into this, it is one of the few things
which really bugs me with Mozilla (and one of the reason that my wifes machine
(W2K) still is configured with Outlook :(
Thanks. It seems that the HKEY_CLASSES_ROOT/mailto registry key is not set by
mozilla at all. However, it doesn't appear to be necessary in order for windows
to handle mailto: correctly. I've only changed the one key (on
HKEY_LOCAL_MACHINE) and that works.

I cannot get mozilla to build on this machine, so I cannot test this patch. I
really think this is something that should be fixed before 1.4: otherwise, this
is going to make Moz mail "broken" for all windows users.

Keywords: qawantedmail6
Target Milestone: --- → mozilla1.4final
per comments of cavin, I've added the nsbeta1 keyword.
Keywords: mail6nsbeta1
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
I tried to build and this patch fails. That may not be the patch's fault.

I tried changing this setting with Thunderbird, and it works. So they must have
fixed this problem in thunderbird. But how?!
Keywords: nsbeta1-
Target Milestone: mozilla1.4final → mozilla1.5alpha
Depends on: 209985
Nice detective work on finding the problem, Jason.  I hope you get the patch 
resolved soon.

> "I tried changing this setting with Thunderbird" -- which setting?  The 
registry key itself?  You can set that "by hand" for Mozilla, too, and it will 
work OK.

> "[the mailto registry key] doesn't appear to be necessary in order for windows
to handle mailto: correctly." -- that's because Windows will use the MAPI 
interface to handle mailto; other apps, however, use the protocol key.

This bug is a dupe of bug 141965, but I'll mark the dupe in the other direction 
since the patch is being handled here.
*** Bug 141965 has been marked as a duplicate of this bug. ***
Following up on a comment from bug 209985:

Under Windows 2000 and XP (but not Win98 or earlier NTs), the HKEY_CLASSES_ROOT 
is a logical hive composed of the HKEY_LOCAL_MACHINE\Software\Classes and 
HKEY_CURRENT_USER\Software\Classes branches.  These systems may require certain 
superuser or admin privs in order to change the HKLM branch.
Comment on attachment 125647 [details] [diff] [review]
A possible fix

The patch doesn't work. It may be a step in the right direction, but right now
it just breaks the "set as default browser" checkbox in prefs altogether.
Attachment #125647 - Attachment is obsolete: true
I still think this patch is the right one. But my computer seems to broken in
this sense, probably from too many manual changes and tests. I simply cannot
find another registry key that does not get changed (And I can't see where
HKEY_Classes_Root/mailto gets set. 

I've done all I can. Hopefully someone else can test this patch, or figure out
what is really going on.
How to test this patch:

1. Build with the patch (of course).
2. Uninstall any mozilla installations.
3. Make another program the default mail app. Preferably, something that plays
very nicely with Windows, like Outlook or Outlook Express.
4. Run mozilla mail, and make it the default mail application. 
5. Check the registry key and what it should be set to in 

The keys in question are
HKEY_CLASSES_ROOT\mailto\shell\open\command (this patch doesn't affect it, and
that may be the problem. I can't find the code that sets this. My guess is that
it doesn't exist!)
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command - This patch fixes
mozilla so it sets this key correctly. I think, at least. It doesn't appear to
work, but I think that's my machine (and perhaps the fact that HKCR isn't being
set correctly. And that's my last word on this bug.

Nominating for 1.5a blocking, since this bug is a huge deal for Windows users.

Flags: blocking1.5a+
The HKEY_CLASSES_ROOT branch is a logical link.  In Win9x and WinNT3/4, HKCR 
*is* HKEY_LOCAL_MACHINE\Software\Classes.  In Win2K/XP, HKCR is a logical 
combination of the HKLM\Software\Classes and HKEY_CURRENT_USER\Software\Classes.

Changes to the HKLM branch affect all users of the system.  In Win2K/XP, if the 
HKCU branch has its own mailto twig defined, that will override the system 
branch's twig.
> Nominating for 1.5a blocking, since this bug is a huge deal for Windows users.

Nominate is "?".
Please don't set milestones unless you'd like to own this bug.

Also, patches need to be generated with "cvs diff -u"
Flags: blocking1.5a+
Keywords: nsbeta1-
Target Milestone: mozilla1.5alpha → ---
Comment on attachment 126820 [details] [diff] [review]
Same patch, new diff with new line numbers

Well, it works on Thunderbird, which is what I'm using now.
Attachment #126820 - Attachment is obsolete: true
*** Bug 214312 has been marked as a duplicate of this bug. ***
*** Bug 206871 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 96717 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Aaron, I disagree that this is a dupe.  As I understand 96717, that is a request 
to add mailto to the list of protocol checkboxes selectable in 
Preferences|Advanced|System, whereas this bug is about making the appropriate 
registry changes when Mozilla installs itself as a default mail client.

As I posted in bug 96717 comment 22, the solution to this bug (actually, a bug 
that's been duped to this) is more useful than what 96717 is apparently intended 
for.

I also point out that there is a patch in process here, which 96717 does not 
have.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Adding mailto: in the checkboxes is useless without the backend.  Bug 96717 is
therefore to handle them both.  I have a patch, but it's in dependent bug
160141.  That bug lays out some architectural changes needed because of the
possible separation of browser and mail.  However, this fix might be able to go
in separately; I'll look into it tonight...
Yes, this is a MAPI issue, which is separate from the other bug.  This fix may
not start the client in all cases; however, if there is a typo here, then that
should get fixed anyway.
Could we please have a target milestone?

Rainer
Jason Abels, I'm afraid your patch is incorrect.  Your statement of the problem, 
in comment 2, correctly identifies the problem as being with the key
  HKEY_CLASSES_ROOT\mailto\shell\open\command
but the line of code in question (currently at line 567 in the file referenced 
in comment 3) is operating on
  HKEY_LOCAL_MACHINE\Software\Clients\Mail\Mozilla
-- and in fact, that subkey *should* be "protocols", not "classes".

There is a patch halfway implemented at bug 202497 which does mostly the right 
thing, not just for mailto: but also for the news-related protocols.  I'm duping 
this bug over there.

*** This bug has been marked as a duplicate of 202497 ***
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → DUPLICATE
Verified dup
Status: RESOLVED → VERIFIED
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: