Closed
Bug 618678
Opened 14 years ago
Closed 5 years ago
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..."]
Categories
(MailNews Core :: Simple MAPI, defect)
Tracking
(blocking-thunderbird5.0 -, blocking-seamonkey2.1 -)
RESOLVED
DUPLICATE
of bug 393302
People
(Reporter: InvisibleSmiley, Unassigned)
References
Details
(Keywords: regression)
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•14 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..."]
Comment 2•14 years ago
|
||
Jens can you find the regression window ?
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 3•14 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•14 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•14 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
Comment 6•14 years ago
|
||
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..."]
Comment 7•14 years ago
|
||
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•14 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..."]
Comment 11•13 years ago
|
||
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•13 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".
Comment 13•13 years ago
|
||
(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.
Description
•