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..."]

NEW
Unassigned

Status

8 years ago
3 years ago

People

(Reporter: InvisibleSmiley, Unassigned)

Tracking

({regression})

Trunk
x86
Windows 7
regression

Firefox Tracking Flags

(blocking-thunderbird5.0 -, blocking-seamonkey2.1 -)

Details

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
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.
Status: UNCONFIRMED → NEW
status-seamonkey2.1: --- → ?
status-thunderbird5.0: --- → ?
Ever confirmed: true
Summary: "Either there is no default mail client..." Windows error message when using Send To/Mail Recipient after setting TB/SM as default mail client [mozMapi32_InUse.dll] → Setting TB/SM as default mail client stores wrong entry in Window registry [mozMapi32_InUse.dll, Send To Mail Recipient, "Either there is no default mail client..."]
Jens can you find the regression window ?
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 3

8 years ago
Bug 614479 may be related, but is not a dupe unless someone verifies a relation by regression window (bug) or code inspection.
Summary: Setting TB/SM as default mail client stores wrong entry in Window registry [mozMapi32_InUse.dll, Send To Mail Recipient, "Either there is no default mail client..."] → [trunk] Setting TB/SM as default mail client stores wrong entry in Window registry [mozMapi32_InUse.dll, Send To Mail Recipient, "Either there is no default mail client..."]
(Reporter)

Comment 4

8 years ago
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...
(Reporter)

Comment 5

8 years ago
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.
Keywords: regressionwindow-wanted
So from what you've said, this doesn't sound like it is a trunk-only issue.
Blocks: 452162
blocking-thunderbird5.0: --- → ?
status-thunderbird5.0: ? → ---
Summary: [trunk] Setting TB/SM as default mail client stores wrong entry in Window registry [mozMapi32_InUse.dll, Send To Mail Recipient, "Either there is no default mail client..."] → Setting TB/SM as default mail client stores wrong entry in Window registry [mozMapi32_InUse.dll, Send To Mail Recipient, "Either there is no default mail client..."]
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
(Reporter)

Comment 8

8 years ago
(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? :-)
Summary: Setting TB/SM as default mail client stores wrong entry in Window registry [mozMapi32_InUse.dll, Send To Mail Recipient, "Either there is no default mail client..."] → 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..."]

Updated

8 years ago
Duplicate of this bug: 626175
sid, fancy taking this on?
blocking-thunderbird5.0: ? → needed
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.
blocking-thunderbird5.0: needed → -

Comment 12

8 years ago
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".
(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....
blocking-seamonkey2.1: --- → -
status-seamonkey2.1: ? → ---
You need to log in before you can comment on or make changes to this bug.