Ref.: https://ask.libreoffice.org/t/libre-write-send-document-not-attachment-created-in-thunderbird/109847/

Works fine for me.

Can you try with an appimage: https://www.libreoffice.org/download/appimage/

Arch Linux 64-bit
Version: 24.8.1.2 (X86_64) / LibreOffice Community
Build ID: 480(Build:2)
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
24.8.1-1
Calc: threaded

TB 115.14.0

Another case: https://ask.libreoffice.org/t/send-option-doesnt-include-the-file/113002

Strange: now it did not work for me an I did not even upgrade my system.

FWIW, and for some kind of a comparison, this works for me too on macOS with:

Version: 24.2.5.2 (AARCH64) / LibreOffice Community
Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59
CPU threads: 8; OS: macOS 15.0.1; UI render: Skia/Raster; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

using Thunderbird:
Version 	128.3.2esr
Identifiant de compilation 	20241015205511

and providing that I enter the full path to the thunderbird executable in the Internet - Email dialog, under LO Preferences.

Same scenario on Ubuntu 24.04.
LO Version: 24.2.6.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 4:24.2.6-0ubuntu0.24.04.1
Calc: threaded

TB version 128.3.1esr (64-bit)
Command line to start Tbird:
/snap/thunderbird/532/usr/lib/thunderbird-bin

WFM Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b0195d40f3abc343b88f767f4fe109a9c1d44347
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

TB Daily 133.0a1 (2024-10-25) (64-bit)

Code pointer (already mentioned in the thread referenced in comment 1):

https://opengrok.libreoffice.org/xref/core/shell/source/unix/misc/senddoc.sh

Note that it's a shell script, which calls an external mailer program; it may need to detect the kind of that program (to decide what command line arguments to use); it passes the reference to the temporarily saved document file in an argument. There may be problems on several stages, including the mailer detection; its kind detection; ability to call that program; ability of that program to access the file.

That's why I asked Gordonbp (in an IRC chat) to provide the *full* command line of the mailer process, when it got created by LibreOffice. I don't know if it's possible / easy on Linux; on Windows, it's quite easy - the full command line (*including arguments*) may be shown even in Task Manager's Details pane, when the respective column is selected to be shown; and there are tools like SysInternals' Process Explorer, that allow to copy it from the process properties dialog. Seeing the *full* command line - including those arguments - may reveal what went wrong. Or alternatively, it's quite easy to edit that shell script right in the LibreOffice installation directory, locally; you may add some diagnostic output, and debug the problem.

(In reply to Mike Kaganski from comment #8)
> Code pointer (already mentioned in the thread referenced in comment 1):
> 
> https://opengrok.libreoffice.org/xref/core/shell/source/unix/misc/senddoc.sh

Oh, I see one possible failure route in that script: the use of mailto: with xdg-email. mailto with attach parameter is considered an attack vector and support for it was first removed in Thunderbird and later in xdg-email: https://gitlab.freedesktop.org/xdg/xdg-utils/-/merge_requests/28

So while Thunderbird with --attach will work, maybe there is a case where xdg-email is invoked with mailto. The script should be updated.

Quote from https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177#note_2127982:

"Note: the real problem here is not that the --attach option exists, that one is okay and useful. The security problem is that the mailto: URL may contain a property that has the same effect but may come from an untrusted source and passed to xdg-email without being filtered (after all xdg-email is supposed to handle that)."

Removing regression keywords as it is unclear if anything changed in LibreOffice.

As Tbird is a snap in Ubuntu 24.04, I saw a comment on another forum, (can't remember where now) that the problem might be with Apparmor. I had a look at the Apparmor website and ran away screaming! Far too difficult for me!

Assuming that "mailto:" in conjunction with "attachment" has something to do with this, the Windows side of the code also needs a rework. Some notes:

shell/source/win32/simplemail/senddoc.cxx: this seems to get built into senddoc.exe, which like it's Linux counterpart takes arguments from the internal code such as --to and --attach

shell/source/win32/simplemail/smplmailclient.cxx: this passes the arguments to senddoc.exe

shell/source/cmdmail/cmdmailsuppl.cxx: I'm guessing this passes the arguments to shell/source/unix/misc/senddoc.sh At least I could not find anything else that would do it.

The code in all the programs should be reworked, so there is never a case where mailto: is used together with the attachment parameter. This is a bit tedious work as the senddoc programs support several email applications.

I don't know what would be the best approach to disentangle the "to" and attachment in case of xdg-email. Always just have an empty "to" in case of xdg-email? We are always sending docs after all, so attachment will always be present. And where do we have UI where the recipients are filled? How broadly are these senddoc programs used?

Windows is unaffected; it uses Simple MAPI, and its methods of providing attachments to the mail agent.

(In reply to Buovjaga from comment #12)
> I don't know what would be the best approach to disentangle the "to" and
> attachment in case of xdg-email. Always just have an empty "to" in case of
> xdg-email? We are always sending docs after all, so attachment will always
> be present. And where do we have UI where the recipients are filled? How
> broadly are these senddoc programs used?

CmdMailSuppl is an implementation of SimpleCommandMail published service [1]. It is used both in our code - for the SfxMailModel::Send (where it allows to have "to" field set), and in external scripts (see e.g. [2]).

So you may safely assume, that "to" is widely used.
But you didn't specify, what is the entanglement here? Do you mean, that the problem that you mentioned in comment 9 only happens when both "to=" and "attach=" are there inside the "mailto:" URI? Can we safely assume, that xdg-email *always* allows to use its separate --attach argument? If so, I don't see a problem: when using xdg-email, just use "--attach=...", not "mailto:...attach=...".

[1] https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1system_1_1SimpleCommandMail.html
[2] https://ask.libreoffice.org/search?q=SimpleCommandMail

(In reply to Mike Kaganski from comment #14)
> (In reply to Buovjaga from comment #12)
> > I don't know what would be the best approach to disentangle the "to" and
> > attachment in case of xdg-email. Always just have an empty "to" in case of
> > xdg-email? We are always sending docs after all, so attachment will always
> > be present. And where do we have UI where the recipients are filled? How
> > broadly are these senddoc programs used?
> 
> CmdMailSuppl is an implementation of SimpleCommandMail published service
> [1]. It is used both in our code - for the SfxMailModel::Send (where it
> allows to have "to" field set), and in external scripts (see e.g. [2]).
> 
> So you may safely assume, that "to" is widely used.
> But you didn't specify, what is the entanglement here? Do you mean, that the
> problem that you mentioned in comment 9 only happens when both "to=" and
> "attach=" are there inside the "mailto:" URI? Can we safely assume, that
> xdg-email *always* allows to use its separate --attach argument? If so, I
> don't see a problem: when using xdg-email, just use "--attach=...", not
> "mailto:...attach=...".

Yeah, the issue is only with mailto:...attach= indeed.

Uninstalled Tbird snap - installed Tbird from ppa.
Problem solved. So it's a Snap (Apparmor) issue.