618678 - Setting TB/SM as default mail client stores wrong entry in Windows registry [mozMapi32_InUse.dll, Send To Mail Recipient, "Either there is no default mail client..."]

Status: RESOLVED DUPLICATE of bug 393302

(MailNews Core :: Simple MAPI, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

With current TB/SM trunk nightly on Win7 x64:

Steps to Reproduce:
1. Set TB or SM as default mail client (TB: Tools/Options/Advanced/General/Check Now, SM: Edit/Preferences/Mail & Newsgroups/Mail)
2. Open the Windows Explorer and execute Send To/Mail Recipient on any file

What happens:
Windows error message "Either there is no default mail client or the current mail client cannot fulfill the messaging request. Please run Microsoft Outlook and set it as the default mail client." appears.
See: http://support.microsoft.com/kb/813745/EN-US/

What should have happened:
TB/SM should have started a mail composition window.

Cause:
HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\(Mozilla Thunderbird|SeaMonkey) contains a string called DLLPath which points to a file that does not exist, namely mozMapi32_InUse.dll. The correct file seems to be mozMapi32.dll, which does exist. If I change the string value to that file, I'm back at bug 614479, i.e. nothing happens (both for TB and SM).

Notes:
- I explicitly disabled Outlook's check to make itself the default.
- The other clients listed under the Mail key are: Hotmail, Microsoft Outlook, Opera, Windows Mail (*not* Windows Live Mail).
- This is 100% reproducible for me, still I won't set this to NEW myself since I want to see this confirmed by somebody else, or maybe me on WinXP (which my laptop is still running) when I find the time.

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

OK, so on WinXP (x86) there is no Windows error message, but the rest still applies there. Adjusting summary, and confirming since I can see this on two machines now.

Comment 2

[Ludovic Hirlimann [:Usul]]

Jens can you find the regression window ?

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

Bug 614479 may be related, but is not a dupe unless someone verifies a relation by regression window (bug) or code inspection.

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

While narrowing down the regression window for bug 614479 (which I found, so it's definitely not a dupe of this one) I found that this bug here has been existing since before 2010-01-01 but I don't have the time to check further now (will do within the next few days, unless someone is faster). TB not providing win32 ZIP files for those points in time is not exactly helpful...

Comment 5

[Jens Hatlak (:InvisibleSmiley)]

SM trunk: OK: 2009-08-08, broken: 2009-08-09 -> bug 497424: port bug 452162
http://hg.mozilla.org/comm-central/rev/d0d99968356c
http://hg.mozilla.org/releases/comm-1.9.1/rev/d0d99968356c

TB trunk: -> bug 452162
http://hg.mozilla.org/comm-central/rev/bbfb7a098337
http://hg.mozilla.org/releases/comm-1.9.1/rev/bbfb7a098337

So the problem is the SetClientsMail macro which now unconditionally writes mozMapi32_InUse.dll ($6) to HKLM / "DLLPath". However, mozMapi32_InUse.dll is only present if the installer of a version including that change was used. That is not the case if:
- you installed SM/TB before that change and used AUS afterward to update the application(s)
- you used ZIP builds (including latest ones from trunk!) instead of installer ones to install the application(s).

Or, the other way round, you're only OK if:
- you used an installer version after the change to install the application(s)
- you copied mozMapi32.dll to mozMapi32_InUse.dll yourself
- you fixed the registry entry yourself.

The majority of people probably uses current installers, so they don't run into this problem. ZIP and AUS users are still affected, though. In case the decision is made to not fix this for TB or not at all, I think we need to at least add a warning to the SM release notes and/or documentation.

Note: bug 499958 looks related, but I don't see what exactly was changed there or whether it was for the better.

Comment 6

[Mark Banner (:standard8)]

So from what you've said, this doesn't sound like it is a trunk-only issue.

Comment 7

[Robert Strong (they/them - no direct email)]

The *_InUse.dll files are copied when updating with app update and an installer build.
http://mxr.mozilla.org/comm-central/source/mail/installer/windows/nsis/shared.nsh#50
http://mxr.mozilla.org/comm-central/source/mail/installer/windows/nsis/shared.nsh#590

With zip builds the PostUpdate process exits early since we've had complaints about changing the registry for zip builds.

One option would be to copy the dll's when setting as default if they don't already exist... the code might already do that but I didn't check

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #7)
> The *_InUse.dll files are copied when updating with app update and an installer
> build.

Oh, maybe my mistake then. I guess I just tested with self-compiled builds and ZIP builds without ever using AUS while checking this bug here and trying to find a regression window. For normal use I use AUS (for both branch and trunk), but I didn't check this bug there.

> With zip builds the PostUpdate process exits early since we've had complaints
> about changing the registry for zip builds.

Ah, OK. Well, as far as the automatic part is concerned I have sympathy for that.

> One option would be to copy the dll's when setting as default if they don't
> already exist... the code might already do that but I didn't check

That sounds like a good idea! If someone actively asks TB/SM to become the default for mail and/or news, file copies and registry changes should be allowed and made no matter what--the user requested to make it work, right? :-)

Comment 10

[Mark Banner (:standard8)]

sid, fancy taking this on?

Comment 11

[Mark Banner (:standard8)]

Now I've re-read comment 8, given that this only affects a few cases of zip installs and not installer versions, this isn't a blocker for 3.3.

Comment 12

[dfghjkjhg]

I am using TB 3.3a4pre (build 2011-03-15).
I never used zip installs, only installer versions (.exe),
but I can't send a file directly from windows explorer via "right-click a file + send to mail recipient from context menu".

Comment 13

[Justin Wood (:Callek)]

(In reply to comment #11)
> Now I've re-read comment 8, given that this only affects a few cases of zip
> installs and not installer versions, this isn't a blocker for 3.3.

I agree, while this would be nice, has been around a long time and our recommended way is installer....