Closed Bug 202497 Opened 22 years ago Closed 20 years ago

Need to set default mailto protocol handler when default mail app

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird1.1

People

(Reporter: mscott, Assigned: mscott)

References

Details

Attachments

(2 files, 5 obsolete files)

Thunderbird needs this and mozilla mail probably wants it to. When you set Mozilla mail as the default app on windows, our mapi code pokes the register and does a bunch of magic for simple mapi to go through mozilla mail. However, we currently don't also set ourselves as the mailto protocol handler when we do the rest of these registry tweaks. If you click on a mailto link in Firebird, it launches OE instead of Mozilla Mail even though Mozilla Mail is registered as the default app. This means setting: HKEY_LOCAL_MACHINE\\Software\\Classes\\mailto\\shell\\open\\command with a value of %app Path% -compose %1 and HKEY_LOCAL_MACHINE\\Software\\Classes\\mailto\\DefaultIcon with a value of %app path%,0 Additional note: if you do this then on win xp, under: Control Panel / Folder Options / FileTypes / URL:Mailto Protocol, we'll show mozilla mail/Thunderbird.
Attached patch start of a patch (obsolete) — Splinter Review
This patch shows how we should set it. I suppose we should remove these lines when unsetting mozilla mail as the default app. That would complete the patch.
This should also be done for news:// protocol. It should also be setup so Windows recognizes it as a mail/news client so that people can use it with IE. No, not me, but other people! In the "Internet Options" control panel, there is an option to select an HTML editor, news reader, mail program, etc. These registry keys are under HKLM\SOFTWARE\Clients but I'm not sure exactly how to get TB to show up in the list (I've tried with the news protocol)
adds news and snews registration for thunderbird
Attachment #120931 - Attachment is obsolete: true
Some comments: Setting the protocol keys on HKEY_LOCAL_MACHINE\Software\Classes works fine for Win9x. Win2K/WinXP require install rights to make a change to that branch. However, any user can make changes to HKEY_CURRENT_USER\Software\Classes and the OS will merge that branch into the HKLM branch to create HKEY_CLASSES_ROOT. For full news protocol support, adding nntp: in addition to news: and snews: would be a good thing.
why isn't this added to Mozilla Suite?
Glad to see the news protocols being added. Lots of times people put links to news servers into web and mail and Win 9x and NT support in the registry is best bet to get Tbird launched to do the work. I manualy hacked my registry for all three news protocols, just not confident I know enough to get them to stick. Tbird is not showing for news in Control Panel | Internet Options yet.
A work in progress. With this latest patch, I can now make us register to be the default news client as well so we pick up nntp urls, news urls, etc.
Attachment #127770 - Attachment is obsolete: true
Confirm that build 20030826 (2003082802 spin) is now showing Tbird for news in Windows control panel internet connections.
This bug might be related to bug 207974? Rainer
*** Bug 207974 has been marked as a duplicate of this bug. ***
Further comments: the patch in this bug (as least as far as mailto goes) appears to already be in the trunk, for Thunderbird builds. So has it been working OK for T-bird? I'm particularly curious about problems with accessing the registry in Win2K/WinXP for non-privileged installs, as I described in comment 4. The command line being used in the patch for mail is mozilla.exe -compose %1 This won't work with current Mozilla, you need to use -mail instead of -compose. Mozilla ought to be able to use -compose, that is bug 209403, which is also Scott's bug. :) I am guessing that patch is also already in place for T-bird? In comment 1, Scott wrote: "I suppose we should remove these lines when unsetting mozilla mail as the default app. That would complete the patch." I would say not just remove them, but restore the previous values, as is done with the changes to the HKLM\Software\Clients branch.
Just downloaded Mozilla 1.5 and was very disappointed to see that this is STILL not fixed! Werner
In answer to comment #12 : if you're not happy with it, feel free to give a patch, or stop crying ! Sorry if it is a little aggressive, but sometimes, it is needed !
I just tried to fix this manually by using either -compose %1 or -mail %1 and neither of them work as noted in this bug and in another related one. And for Frederic's comment: I would hope that Mozilla does not expect every user to be a C++ expert! But that one is nevertheless allowed to mention a problem and/or to bring it up again if it is not fixed in the latest official release!
The -mail capability of opening mailto: URLs was broken during 1.5 development; see bug 220306. Until such point as this might get fixed, you can use -browser -- unless that gets broken too.
*** Bug 224824 has been marked as a duplicate of this bug. ***
I´ve just read a chain of bugs duped to another leading to this bug. bug 141965 -> bug 207947 -> bug 202497. Each one tells a lot about registry keys, but the problem is still unsolved. Reading this bug, I assume, it is solved for TBird. Can it be solved for Mozilla Mail too? Win98 has still a large market share, and if people can´t register Mozilla Mail as default, they´ll stick to whatever they have, when they buy a new computer, with a new OS.
Here is an updated patch which gets us much closer. Unfortunately I'm having some problems and I just can't wrap my head around all of these registry key settings to figure out. I'm hoping by posting this pach Mike Cowperthwaite or someone else can help me figure out what I'm still missing. For starters: * Ignore the issue of writing to local_machine verses current user. We'll talk about that when this patch actually works. Scenarios: 1) If you set thunderbird to be the default news client in thunderbird, things work great. news, nttp and snews links all get sent to thunderbird and it loads fine. 2) I can bring up IE's Tools / Options / Programs dialog and it shows thunderbird as the default news client. So things look great. PROBLEMS: 3) Unsent thunderbird as the default news client in thunderbird. Outlook was the previous default news handler. Now click on a news url, IE throws up an error dialog saying news:///< ....> cannot be found. IE's program dialog shows OE as the default news client. Thunderbird changes Software\Clients\News to point to OE. Thunderbird changes \Classes\news(snews, nntp)\shell\open\command to point back to OE. Yet it still does not work. I must be missing something else that needs to be reset when removing us as the default client. Changing the default news client from IE's Program dialog works fine. **Need help here**. 4) Setting Thunderbird as the default news client from IE's Program dialog does not work. Cliking on news links fail to launch thunderbird. It only works when you set it through Thunderbird. However, I can verify that IE is changing \Software\Classes\news(snews,nntp)\shell\open\command to launch thunderbird like it should. IE has also changed \Software\Clients\News to list Mozilla Thunderbird. Again, is there some other key I'm still missing that needs to be set? If anyone can help explain what is going on here, I would much appreciate it. I am drowning right now :)
Attachment #130442 - Attachment is obsolete: true
Hmmm, maybe you need "::SendMessageTimeout" which, AFAIK, informs other processes about the registry changes you've just made. Take a look at /mozilla/xpfe/components/winhooks/nsWindowsHooksUtil.cpp for an example. Warning, that program is buggy as well, so please don't treat it as the proper way to do things.
That tip helped out a lot. Thanks! With this improved patch, I am now able to set / unset thunderbird as the default news app from IE's program dialog. I still have problems when unsetting thunderbird as the default news app from within thunderbird. I don't believe I am properly adding back all of the right protocol subkeys for the previous default mailer. Does anyone know if there is a short cut windows registry API that makes it easy to "clone" a key and all of it's subkeys and add them somewhere else in the registry? I want to easily take: \Software\Clients\News\<some news ap.\Protocols\news and all of that keys children and insert them into \Software\Classes\news
Attachment #135778 - Attachment is obsolete: true
Well, there isn't a "real" API for copying registry data from once location to another. However, there are ways to do it. From looking at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/registry_functions.asp I can see that ::RegSaveKey and ::RegRestoreKey could work, except for the hassle with external filenames. There is also the shell function SHCopyKey that can be used with the registry. However, I haven't had much luck getting them to work properly, maybe you will have more luck.
Scott: Here is a link to a recursive function to copy a key and all of it's sub-keys. edit and mold to your hearts content. http://www.codeproject.com/system/registrykeycopy.asp Kevin
This is also a nice summary of all of the stuff that changes for client changes with the IE Programs panel. http://msdn.microsoft.com/workshop/browser/configuration/clientreg/clientregistrylayout.asp Kevin
Thanks for the resources everyone. I now have a patch which seems to be doing the right thing for mail and news now. In addition, I can now change the default apps for news and mail from IE's Programs tab under internet options and everything still works. Yippee! The remaining issue: 1) Resolve Mike's comments about when to write these settings in HKEY_CURRENT_USER instead of always in HKEY_LOCAL_MACHINE like we do now.
Attachment #135787 - Attachment is obsolete: true
I'd like to comment on ------- Additional Comment #13 From Frederic Bezies 2003-11-02 01:26 ------- I spent a couple of hours with lxr.mozilla.org today trying to find where command line arguments are handled since I had the same problem. But you know what? I *am* a C++ expert and I just couldn't find it. It looked like you registered "COM" objects to handle specific command line arguments but I was never able to find the code that actually did something! Or maybe that's the bug? The amount of preprocessor magic going on is rather daunting. Anyway, I won't use bugzilla as a forum anymore. I just thought it needed to be said.
Well, a debate about HKCU vs HKLM. What Mike states in comment #4 is correct based on what I've read as well. In fact, you need to accomodate any error on any registry command as WinXP and WinNT have ACL's for the registry as a whole, and in part. I'd prefer HKLM as Mozilla doesn't handle multiple users under WinXP and WinNT very well anyway, and it isn't an issue under Win9x. Having said that, I recall a comment from a bug I'm working on (albiet slowly), try HKLM first, if that fails, try HKCU before returning an error. Your patch looks excellent (from a Win Registry API point of view). My only comment is to make sure that any opened key gets closed ASAP to prevent any memory or resource leaks.
The issue of non-privileged users being unable to write to HKLM is real. However, it's a flaw shared by Windows itself -- right now, at least some of those default-client settings require an administrator to set them up. The default account on Win2K and WinXP is admin, and the users who don't know what that means are unlikely to change that; whereas the users who *do* know what that means know how to handle it. The exception is for some corporate drone who's been given a machine where she only knows the password to her user account; chances are even software installs are disabled on such a machine, so she'll have to get permission to even install Mozilla. A couple of nits in that patch: 1) Are these items supposed to be case-identical? +++ mapi/mapihook/public/nsIMapiRegistry.idl18 Nov 2003 23:05:57 -0000 + void registerMailAndNewsClient(); +++ mapi/mapihook/src/nsMapiRegistry.cpp18 Nov 2003 23:05:57 -0000 +NS_IMETHODIMP nsMapiRegistry::RegisterMailAndNewsClient() 2) In nsMapiRegistryUtils.cpp: MOZ_CLIENT_MAIL_KEY and MOZ_CLIENT_MAIL_KEY are defined, but their equivalent hardcoded strings are being used all over the place, e.g. IsDefaultMailClient(). 3) Is this supposed to be here? This looks like you're undoing the fix for bug 140649. Index: base/prefs/resources/content/AccountManager.js - if (account == accountManager.defaultAccount || - !server.canBeDefaultServer || - account.identities.Count() < 1) + if (account.identities.Count() < 1) canSetDefault = false;
Thanks Mike. About the HKLM issue, is your stance that we should be doing nothing differently than what we are right now in this patch then? Or do you have a belief that we should be writing to HKCU instead of HKLM in some cases? Thanks for the review tips, I'll take a look at incorporating them. #3 was definetly not supposed to be attached to this patch.
I think the proper thing to do is hard to define. In order to be registered as a possible client, Mozilla *has* to be able to write its Client keys to HKLM (not necessarily Admin, Superuser will do). This is necessary to get the MAPI interface working; if that's possible, then setting the HKLM protocol keys is possible. The MAPI config is, unfortunately, global to all users; given that, is it worth the trouble to individualize the protocol keys? I'm guessing not. Therefore, I'd say the best thing to do is continue to write to HKLM, but be sure to check for failure and let the user know that Moz was unable to make itself the default. One other thing I forgot to mention: the patch is assuming -compose will do the trick, but that isn't working (yet) on URLs; and since 1.5, using the -mail switch with a mailto: URL no longer opens a compose window, either. Once that's been fixed, I trust you'll be taking out the #ifdef MOZ_THUNDERBIRD conditionality. I do want to see this in the suite. :)
*** Bug 217945 has been marked as a duplicate of this bug. ***
*** Bug 216834 has been marked as a duplicate of this bug. ***
*** Bug 219796 has been marked as a duplicate of this bug. ***
Attached patch additional fixSplinter Review
this patch goes on top of the earlier patch. It fixes a problem when unregistering thunderbird as your default news client, we still think we are registered because we are looking at the wrong key value.
*** Bug 235961 has been marked as a duplicate of this bug. ***
Adding dependency on the but about support for -compose. Incidentally, regarding comment 28 & 29 -- I had occasion a month or so back to attempt installing Mozilla on a Win2K system for which I did not have install privs. It couldn't do it at all -- apparently, the GRE install requires those privileges too. So, if the user is able to install Mozilla at all, he'll have the rights to make the registry changes needed to set the defaults and change the mailto: keys.
Depends on: 236774
*** Bug 241556 has been marked as a duplicate of this bug. ***
Le'see, just a quick scan shows Bug#202497, Bug#220306, Bug#220753, Bug#241381, Bug#242255 as open mailto bugs. The following combinations are busted on MSwindows-XP: F-Fox 2004-04-25-09-trunk T-Bird 2004-04-25-00-trunk; F-Fox 2004-05-02-09-trunk T-Bird 2004-05-02-00-trunk. On XP this was fixed once, but I can't seem to find that bug#. Anyway, it's baaaaack! Obviously, this stuff if fragile magic. PS, before anyone tells me to, YES the published registry patch is applied - and in fact I found another likely registry key, but it didn't work.
About Comment 35, there's a reported bug about GRE and I think it's in the Firefox roadmap.
Blocks: 251401
*** Bug 249333 has been marked as a duplicate of this bug. ***
*** Bug 254392 has been marked as a duplicate of this bug. ***
*** Bug 247999 has been marked as a duplicate of this bug. ***
*** Bug 251161 has been marked as a duplicate of this bug. ***
*** Bug 234915 has been marked as a duplicate of this bug. ***
*** Bug 260265 has been marked as a duplicate of this bug. ***
Here's an easy test, I learned after discovering this problem: Use "Start Menu->Run..." and then enter "mailto:". If Mozilla is misconfigured, Outlook Express loads instead. A workaround was posted at http://texturizer.net/firefox/faq.html#email
*** Bug 263431 has been marked as a duplicate of this bug. ***
*** Bug 269836 has been marked as a duplicate of this bug. ***
*** Bug 268947 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 273141 has been marked as a duplicate of this bug. ***
please don't ask me to fix this myself. my role in the mozilla foundation is QA, it will remain that way for the unforseable future. if anyone would like my role to change please contact me outside of the bug report area. The same goes for contacting any other QA personnel. It is not acceptable for developers to constantly be poking at QA personnel who tell developers what should be fixed. That's the role of QA, if you don't like it, deal with it. if there is no developer that understands the correct registry settings to set a default mail client/handle the mailto protocol. then someone (aka a mozilla developer) should call microsoft and get help. this should be solved in 1 day. I cannot stress this enough. Firefox is supposed to be a professional piece of software. Although this may be a Mozilla Suite/Thunderbird issue it sure makes Firefox look amateurish because it's not loading the proper compose window from a user perspective. Please fix for next release!
Flags: blocking1.8a6?
*** Bug 269467 has been marked as a duplicate of this bug. ***
*** Bug 273510 has been marked as a duplicate of this bug. ***
*** Bug 276014 has been marked as a duplicate of this bug. ***
How about some sort of prize or recognition for the person who finally fixes issues like this -- the ones with dozens of duplicate reports that have been hanging on for years. Recognition. Goodies. Fame. What can we do for the person who fixes this?
An elective copy of any program in the Mozilla suite? :-)
It´s not even complex to fix because one jsut newed to learn to write correct thinks to register and only to few places. I think one who knows windows register well can fixure this out in 1-2 hours. I could make it maybe in 10 hours ;) But I´m not at home just now so I don´t have access to source and register. So someone well in windows development should take over this bug.
Scott, do you think you'd have time to look into this for 1.8a6? If not, then maybe for beta?
not going to block the release for this but we'd consider a reviewed patch if it's available in time.
Flags: blocking1.8a6? → blocking1.8a6-
*** Bug 272625 has been marked as a duplicate of this bug. ***
This landed on the trunk quite some time ago as Bug #277833
Status: NEW → RESOLVED
Closed: 20 years ago
Component: MailNews: Simple MAPI → General
Flags: blocking1.8a6-
Product: Core → Thunderbird
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird1.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: