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
I will check that soon - Reported with Bug Submission Assistant -
Writer uses MAPI interface handler, a system-wide setting.
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?
@David: May be Help should be more meaningful telling what "the default ail client" is.
> 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 ?
[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.
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. @Lenge 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.
@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.
@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?
Never independently confirmed by QA team - moving to UNCONFIRMED to make sure they see it. Thanks for your patience and understanding.
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?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! This NEEDINFO Message was generated on: 2015-06-08 Warm Regards, QA Team
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.
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. Results: 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. http://kb.mozillazine.org/MAPI_Support C) Reset Protocol handlers back to Default "Thunderbird" ,as system was originaly installed. (and confirmed that it does work). Conclusion: 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) ~Richard
Created attachment 116511 [details] Testing Script (OpenDocumentText - SWRITER) Testing Script:
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.
Created attachment 116513 [details] LibreOffice_SetAssociations_forFossaMail_Capture.JPG 1st setting capture. 11:26 PM
Created attachment 116514 [details] Attempt to Send
Created attachment 116515 [details] LO Warning - no Email configured LibreOffice Cried foul when its previous application was not found.
set to NEW from comment #14. Bets regards. JBF
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
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 MassPing-UntouchedBug
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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I cannot reproduce the problem on Windows 10 with Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL FTR: some time ago, in commit c2f7759e85f3e5cc9f56aaf03eefa0f1ba834734, I cleaned up our Simple MAPI use, and removed the explicit loading of mapi32.dll (which *possibly* could be the reason for the problem - in a case when for a reason, the DLL would happen to be wrong). Now we only use Windows API [1], which should do The Right Thing(TM). So I assume this would be WORKSFORME. [1] https://docs.microsoft.com/en-us/windows/win32/api/mapiunicodehelp/nf-mapiunicodehelp-mapisendmailhelper