Bug 41725 - CONFIGURATION: HKCU defined mail client should be used instead of HKLM defined by "Document as E-mail" toolbar button
Summary: CONFIGURATION: HKCU defined mail client should be used instead of HKLM define...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
3.4.3 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: File-Send
  Show dependency treegraph
Reported: 2011-10-12 10:19 UTC by Lenge
Modified: 2020-02-29 03:02 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Testing Script (OpenDocumentText - SWRITER) (32.42 KB, application/octet-stream)
2015-06-14 06:04 UTC, Richard_416282
LO 4.4 Send-as-document FAILS (21.07 KB, image/jpeg)
2015-06-14 06:10 UTC, Richard_416282
LibreOffice_SetAssociations_forFossaMail_Capture.JPG (69.41 KB, image/jpeg)
2015-06-14 06:13 UTC, Richard_416282
Attempt to Send (20.27 KB, image/jpeg)
2015-06-14 06:16 UTC, Richard_416282
LO Warning - no Email configured (20.30 KB, image/jpeg)
2015-06-14 06:19 UTC, Richard_416282

Note You need to log in before you can comment on or make changes to this bug.
Description Lenge 2011-10-12 10:19:09 UTC
A small Windows-specific bug that has survived at least since OOo 3.2: The "Document as E-mail" toolbar button (usually the 4th button in the main toolbar) opens the wrong mail client if the current user has specified a default client that differs from the respective admin setting.

The toolbar button seems to always use the mail client that is stored in the registry at "HKLM\Software\Clients\Mail", which is an admin-only setting that normal users cannot change.

If the current user has set his own default client (stored at "HKCU\Software\Clients\Mail"), this setting is supposed to have precedence over the admin setting. However, it is ignored by the above toolbar button (same in Writer and Calc, not sure about the other apps).

Unlike this specific toolbar button, the rest of LibreOffice (and all other apps that I came across) behaves as expected: If you click a "mailto" URL in a document, the correct (user-specific) mail client opens.

Not a big deal, but should be fixed someday.

Steps to reproduce:
1. On a Windows XP machine, leave the "HKLM\Software\Clients\Mail" admin setting at its default value "Outlook Express".
2. Login as a user and set a different user-specific default mail client (e. g. by clicking the accoring GUI option in Thunderbird, or by directly writing "Mozilla Thunderbird" to "HKCU\Software\Clients\Mail"). 
3. While logged in as the above user, run Writer (or Calc) and click the "Document as E-mail" toolbar button.

Current behavior:
Outlook Express is opened (which is wrong).

Expected behavior:
Mozilla Thunderbird should open instead.

Platform (if different than the browser): 
Windows XP
Browser: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Comment 1 Rainer Bielefeld Retired 2011-10-12 23:11:31 UTC
I will check that soon
- Reported with Bug Submission Assistant -
Comment 2 Urmas 2012-02-26 01:40:24 UTC
Writer uses MAPI interface handler, a system-wide setting.
Comment 3 Lenge 2012-02-26 13:08:54 UTC
Cite: "Writer uses MAPI interface handler, a system-wide setting."

That is more of a different bug description instead of a resolution. Is it really an explicit design goal to make Writer ignore the user-specific mail client and thereby enforce one that the currently logged-in user has not even configured to work for him? And, if so, then why is this behavior only present for this one toolbar button?

I sincerely think that this button should behave just as if any "mailto:" link was clicked in any LibreOffice application (even in Writer!) - which opens the correct (user-specific) mail client.

Or is there any specific reason for insisting on the current behavior that I might have missed?
Comment 4 Rainer Bielefeld Retired 2012-02-26 21:15:36 UTC
May be Help should be more meaningful telling what "the default ail client" is.
Comment 5 Michael Meeks 2012-02-27 01:55:52 UTC
> That is more of a different bug description instead of a resolution. Is it
> really an explicit design goal to make Writer ignore the user-specific mail
> client and thereby enforce one that the currently logged-in user has not even
> configured to work for him? And, if so, then why is this behavior only present
> for this one toolbar button?

If you can find an API that can be used to -send- mail - ie. not just launch a mail client, but populate it with contents, and preferably silently send the mail out for mail-merge, and then work on replacing the MAPI code [ which provides just such an API ], with this new API then you're welcome to ! :-)

In the meantime to resolve the inconsistency, we could remove / hide the - 'mailto:' handler selection on Windows I suppose - if that makes you happy, and try to track / deduce that setting from whatever Windows is using for the MAPI library: would that solve the problem for you ?
Comment 6 Lenge 2012-02-27 06:16:20 UTC
[b]@Michael:[/b] If you are looking for an API to *silently* send emails without any mail client showing up, you can use the according functionality of Microsoft's Collaborative Data Objects (CDO). I have example code (Excel VBA) on how to use it if you are interested. There also are other ways such as the free BLAT SMTP engine (www.blat.net). However, for silently sending emails without user interaction, you'd need the user to pre-define an according SMTP account or provide your own.

But, concerning the "Document as E-mail" toolbar button, I think the intended behavior is not to have it sending an email silently (to whom?), but to open the user's mail client for a new email with the current LibreOffice document already attached. At least this is what it currently does, and it works independent of a specific email client (I checked with Outlook, Outlook Express, and Thunderbird). The problem is just that it insists on using the HKLM (admin-only) instead of the HKCU (user) defined mail client.

I admit I am not aware of how to make the MAPI interface use the HKCU client, or of an alternative API to do it (which does not mean that there is none; I'll keep my eyes open). Yet still, I think my request is reasonable and should be resolved, so we should keep it open.

[cite]In the meantime to resolve the inconsistency, we could remove / hide the -
'mailto:' handler selection on Windows I suppose [...][/cite]

The current "mailto:" handler implementation behaves exactly as expected and consistent with Windows itself and almost all other applications out there, so there is no need to change it in any way.
Comment 7 Rainer Bielefeld Retired 2012-02-27 09:19:02 UTC
I failed to reproduce the problem with WIN XP on VirtualBox, but may because I did not succeed in creating different mail settings in WIN System-Settings-Internet - Mail program for User and admin.

It will not attract much interest if there is a problem after some Registry handicraft. 

It would be useful if you can contribute a step by step instruction for the standard "Admin and User are the same" WIN XP user using Seamonkey (or thunderbird) how to create a second WIN user account with a different Mail client (OE) and how to reproduce the problem with a little WRITER document only containing mail link.
Comment 8 Lenge 2012-02-27 10:42:15 UTC
@Rainer: Here are step-by-step instructions to reproduce the bug:

1. A freshly installed Windows XP comes with a built-in "Administrator" account, and the system-wide (HKLM) mail client is "Outlook Express" by default.
2. Log in as "Administrator" and create a non-admin "User" account (a member of group "Users", but not "Administrators").
3. Still as admin, install LibreOffice and Thunderbird, but do not change the admin's default mail client. No need to run Thunderbird as admin.
4. Now log in as "User", run and config Thunderbird. At "Tools/Options.../Advanced/General", use the "System Integration" options to make Thunderbird the default mail client. (This will change the HKCU option to Thunderbird, while the system-wide HKLM setting still remains Outlook Express.)
5. Still as "User", run Writer and press the "Document as E-mail" toolbar button. This will (incorrectly) try to open Outlook Express (HKLM setting) instead of Thunderbird (HKCU setting).
6. In Writer, type "mailto:whoever@whatever.whereever" and let it automatically convert into a hyperlink after typing an additional whitespace. Now Ctrl-Click the hyperlink and see Thunderbird open (as should be).

Can you reproduce the issue this way?

The point is that non-admin users cannot change the system-wide (HKLM) setting (which is typically accessed via "Control Panel/Internet Options/Programs/E-mail"), but may still select their own user-specific default mail client (via the HKCU setting, with is accessed e. g. by Thunderbird's above config option). So, if both settings exist (and possibly differ), the HKCU one is to be used.
Comment 9 Lenge 2012-02-27 11:22:34 UTC
@Rainer: I just found a simpler way to reproduce the issue that only deals with a single admin account (e. g. the built-in "Administrator") while no additional user account is required:

- As already said, the system wide "HKLM\Software\Clients\Mail" setting is typically accessed via the "Control Panel/Internet
Options/Programs/E-mail" GUI option, and the corresponding user-specific HKCU setting is accessed via the according GUI option of the mail client (such as Thunderbird). So both options can be set without directly manipulating the registry.

- After a fresh Windows XP install, the system-wide "HKLM\Software\Clients\Mail" setting is "Outlook Express", and the user-specific "HKCU\Software\Clients" does not yet exist.

- When installing Thunderbird and setting it to the default mail client, "HKCU\Software\Clients\Mail" is created and points to "Mozilla Thunderbird". The system-wide HKLM setting is left unchanged and still points to "Outlook Express".

- This is enough to reproduce the buggy behavior of Writer's "Document as E-mail" toolbar button. Can you?
Comment 10 Joel Madero 2014-11-05 03:59:30 UTC
Never independently confirmed by QA team - moving to UNCONFIRMED to make sure they see it. Thanks for your patience and understanding.
Comment 11 Buovjaga 2014-11-16 10:40:45 UTC
Apologies for the "NEEDINFO without testing" dirty trick, but I was tempted to ask, if this is still relevant with XP being EOL ie. does this happen with Win 7 or 8?
Comment 12 QA Administrators 2015-06-08 14:28:28 UTC Comment hidden (obsolete)
Comment 13 Lenge 2015-06-10 00:41:32 UTC
I don't have Windows 7 at hand on a regular basis, but got the opportunity to do some quick testing today - and it seems the bug is still present on Windows 7. However, it would be great if somebody could confirm with some more in-depth testing on Windows 7 and above.
Comment 14 Richard_416282 2015-06-14 05:42:48 UTC
OK. here goes:

Win7-x64_Home User.
System Split between two modes: ADMIN and USER.
User has all of the APPS, and DATA.
ADMIN is used just for security, and administration.

Tried to mimic bug.

Received two modes of failure:

A) Expected result (Failure) as described in original Poster.

B) Application Hang of LibreOffice. (system did not know what to do with mail).

and finally an attempt at correction.

So, as an ordinary user from the puch-card days, and 80 column field limits, discovered some(!) strange (to me) operations of Win7.

A) Initially, thought by changing "Default Actions" for the Application "FossaMail" would auto -magically set all keys and protocols to support MAPI.

-was proven wrong by experimentation.

B) Secondly, wondered if its more detailed , than an 'ordinary' user like myself could figure out. (it is :-))

C) Attempted to restore to "Normal" operation, and undo all of the changes.


A) Changing the "Default Protocols and filetypes" broke windows so it could no longer send anything via "File : Send : Document as E-mail" from within LO 3.5, 4,4 and 5.1 alpha.

B) Stumbled onto MAPI handling in MozillaZine.

C) Reset Protocol handlers back to Default "Thunderbird" ,as system was originaly installed. (and confirmed that it does work).


 This "bug", *may* be a problem more to do with the implementaion of the MAPI protocol (BASIC or EXTENDED) in Windows, rather than with LO, and the Calling of the particular handler.

I open the *may* because, there really is no ambiguous way to divine the difference between Mailto:, MAILTO:, and mailto: when you are dealing with conflicting protocols, undefined paramaters that work between Microsoft Programs for mail (Outlook, Outlook Express) (proprietary executable), and OpenSource, (Netscape>Mozilla-Mail, FossaMail, and LibreOffice, OOo).

If you ignore the case of the three terms above, they are the same.
But if you do not ignore case handling, then you could have three different programs, handling three different implementaions of 1 protocol (MailTo:).

So, although it currently (2015-06) is flagged as UNCONFIRMED, I vote that it be changed to "Confirmed", as the bug appears with my installation.

How to fix the bug, I am not a guru on MAPI (yet.) so I leave with my observations, and attachments (screen shots in JPEG)

Comment 15 Richard_416282 2015-06-14 06:04:46 UTC
Created attachment 116511 [details]
Testing Script (OpenDocumentText - SWRITER)

Testing Script:
Comment 16 Richard_416282 2015-06-14 06:10:24 UTC
Created attachment 116512 [details]
LO 4.4 Send-as-document FAILS

Email: There is no program associated to perform the requested action. Please install an email program or, if one is already installed, create an association in the Default Programs control panel.
Comment 17 Richard_416282 2015-06-14 06:13:27 UTC
Created attachment 116513 [details]

1st setting capture. 11:26 PM
Comment 18 Richard_416282 2015-06-14 06:16:15 UTC
Created attachment 116514 [details]
Attempt to Send
Comment 19 Richard_416282 2015-06-14 06:19:53 UTC
Created attachment 116515 [details]
LO Warning - no Email configured

LibreOffice Cried foul when its previous application was not found.
Comment 20 Jean-Baptiste Faure 2015-08-01 05:18:06 UTC
set to NEW from comment #14.

Bets regards. JBF
Comment 21 QA Administrators 2016-09-20 10:20:40 UTC Comment hidden (obsolete)
Comment 22 QA Administrators 2020-02-29 03:02:43 UTC
Dear Lenge,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team