Open Bug 1800328 Opened 2 years ago Updated 7 months ago

Random empty text files with .part extension (e.g. LLJ57TEH.odt.part) appear in desktop when opening attachments from composition

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Version:
Thunderbird 102
Platform:
Unspecified
Linux
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: vms367, Unassigned, NeedInfo)

References

Details

Attachments

(10 files)

Captura de pantalla_2022-11-12_16-45-04.png
249.68 KB, image/png
Details
simplescreenrecorder-2022-11-13_12.03.55.mkv
688.41 KB, video/x-matroska
Details
simplescreenrecorder-2022-11-13_12.21.03.mkv
1.63 MB, video/x-matroska
Details
Captura de pantalla_2022-11-13_14-01-29.png
93.43 KB, image/png
Details
vokoscreenNG-2022-11-13_15-21-49.mkv
3.25 MB, video/x-matroska
Details
simplescreenrecorder-2023-05-02_16.10.15.mkv
1.11 MB, video/x-matroska
Details
simplescreenrecorder-2023-05-02_16.11.30.mkv
2.19 MB, video/x-matroska
Details
simplescreenrecorder-2023-05-02_16.15.06.mkv
1.29 MB, video/x-matroska
Details
simplescreenrecorder-2023-05-02_16.35.47.mkv
586.83 KB, video/x-matroska
Details
simplescreenrecorder-2023-05-02_16.42.54.mkv
673.00 KB, video/x-matroska
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

If I open an attachment of an email that I'm redacting, then automatically shows up such empty text files, with the extension of the type of file I opened and ending with ".part". So, if I open a mp4 video file, it appears in the desktop a file like this one: 10v4kMKn.mp4.part or if I open a photo, then it appears in the desktop another empty text file, like this: 2tefkA_u.jpeg.part.

As I open often documents while writing an email, then most times it appear files like: LLJ57TEH.odt.part or sb3Flnea.docx.part.

But if I open a webpage, then it appears something like: W57aLebY.html.part.

And this happens always.

Actual results:

Random empty text files appear in desktop each time I open attachments while editing emails in Thunderbird.

Expected results:

No random empty text files appear in desktop each time I open attachments while editing emails in Thunderbird.

vms367, that's odd! I've tried opening attachments from composition on Windows 10 and the same does not happen for me on 102.4.2 (64-bit).
.part files are typically temporary files when downloading files from web browser, but we're not exactly downloading, and definitely those files shouldn't end up on your desktop. It's a bit unlikely, but not impossible that this is a bug in TB.

  • Can you try using original install from thunderbird.net (as opposed to using TB from distro)
  • Does this problem still happen with ≡ > Help > Troubleshoot Mode…? (Please clear all old .part files before so they won't confuse the result)
  • Can you take a screenshot of your settings for ≡ > Settings > General > Files & Attachments including the radio option below that, and attach here viaAttach New File` button above comment 0 ?
  • Can you please file exact STR, like every click and dialog you go through? Numbered list of steps is needed. Like this:
    1. Compose message with test.odt attachment
    2. double-click on test.odt attachment from composition window
    3. ....
Severity: -- → S3
Component: Untriaged → Message Compose Window
Flags: needinfo?(vms367)
OS: Unspecified → Linux
Summary: Random empty text files appear in desktop each time I open attachments while editing emails in Thunderbird → Random empty text files with .part extension (e.g. LLJ57TEH.odt.part) appear in desktop when opening attachments from composition

So, in Xubuntu 22.04 LTS, I have made 2 videos and I took a screenshot, as per your request.

Both videos reflect the behaviour of Thunderbird, current version downloaded from https://www.thunderbird.net/es-ES/

The first video shows what happens in normal mode. Yes, it creates a .part file, with a middle name based on the type of attached file.

The second video shows what happens in trouble-shoot mode; It creates it, also.

There are other people to whom this is happening too. Below I send you a link to similar problem:
https://www.bleepingcomputer.com/forums/t/770866/random-html-files-keep-appearing-on-my-desktop-seemingly-at-random/

They believe it's perhaps caused by a Windows malware, but I think it is not the case, but maybe a Thunderbird bug.

Flags: needinfo?(vms367)

This is the she second video.

BTW, I tested also a fresh install of Kubuntu 22.04 LTS and... yep, also happens under KDE.

Here goes the screenshot of my settings for ≡ > Settings > General > Files & Attachments.

I'm not sure what you mean about "including the radio option below that", though.

In Windows 10 it also happens, but:

  • Only appear those ".part" files, the first time a type of file is opened and if it's not selected in Thunderbird the program to open such file. So to reproduce this behaviour I had to select always ask with what program to open such file type in TB, Settings, Files & Attachments.
  • Only appear it once clic is done in the attachment, and during the TB window for selecting the program to open it pops up; So, once the file is already open or it is cancelled such pop up window to choose with what program to open it, in both cases the ".part" file vanishes from the desktop.
  • But in Linux don't vanish such files.

I attach you the respective video made in Windows 10.

(In reply to vms367@hotmail.com from comment #5)

Created attachment 9303201 [details]
vokoscreenNG-2022-11-13_15-21-49.mkv

In Windows 10 it also happens, but:

  • Only appear those ".part" files, the first time a type of file is opened and if it's not selected in Thunderbird the program to open such file. So to reproduce this behaviour I had to select always ask with what program to open such file type in TB, Settings, Files & Attachments.
  • Only appear it once click is done in the attachment, and during the TB window for selecting the program to open it pops up; So, once the file is already open or it is cancelled such pop up window to choose with what program to open it, in both cases the ".part" file vanishes from the desktop.
  • But in Linux don't vanish such files.

I attach you the respective video made in Windows 10.

Further tests result on that in, both, Windows and Linux, when TB asks for what should do with the attached file (either, to open with "X" program or to save it), appears temporarily the ".part" file in the desktop. But once the user makes a choice then the .part file vanishes from desktop.

But if TB already knows what to do with the attached file (generally to open with "X" program), then the .part file does not vanish; So successive openings of the attached files while composing an email cause accumulation of those ".part" files in the desktop.

Can confirm that this issue exists on Thunderbird 102.4.2 (64-bit), as tested on Linux Mint 21 with all available updates applied at the moment of writing.

In Thunderbird click "Write", then "Attach", select few files (in my case two PDF files from Documents directory) and click "Open" to attach them. Now double click one of the attached files and it opens in "Document Viewer" program (Xreader). At the same time a file "{random_string}.html.part" is created on Desktop. File is empty (0 bytes). Sending message, discarding message, closing "Document Viewer" and exiting Thunderbird does not remove "part" file.

When "open/save" dialog is used (open actions are deleted from Settings), "part" file is created when dialog window opens and deleted after cancelling or clicking "OK" after choosing program to open file with. In my case if I choose "Save" option, the attached PDF file is saved empty (0 bytes) and "part" file is not deleted.
Also, "part" files are not deleted when I have default program set to open attached files. Subsequent opening and closing of file attached in composition window does not create new "part" file, even if I delete the old one.
Seems like part files are used to temporarily store contents of attachments, but might not be working correctly in some corner cases. Could be related to changes Firefox made, where /tmp directory are not used to store temporary download files and they always end up in Downloads directory, even if user is just viewing file.

No similar issues were observed in received messages views. Seems like attachments in composition window are working a bit different as compared to other locations. Could it be that code is not shared and was not updated?

Interesting note: in Settings, "Files & Attachments" section I see content type "HTML document" set to "Use xreader", and PDF - "Always ask". Radio selection is set to "Always ask me where to save files". Somehow PDF files are recognized as HTML files in composition window, hence the "html.part" extension. While opening same PDF attachments in "Inbox" or "Sent" folders shows them correctly recognized as "PDF" files, and no "part" files are created. But this might be totally different issue, please advise, if I should open new bug report for it.

Feel free to ping me if more information is needed.

Issue can be reproduced in Beta version of Thunderbird 108.0b1 (64-bit) on Linux Mint 21. Only difference so far, that each time attachment is opened from composition window, it creates a new "part" file.

Issue still can be reproduced in Thunderbird 110.0b1 (64-bit) Beta on Linux Mint 21.

If correct solution takes too much time, maybe some workaround could be introduced, as deleting html.part files from desktop gets annoying really quickly. Maybe add dot in front of filename to make them hidden? Or at least store them in "cache" directory?

This bug is still present in Thunderbird 102.10.0. And yes it can be annoying because the .part files populate the desktop and mix among the other applications and files icons there. So one may end deleting some genuine file by mistake when trying to remove manually those part files again and again, as TB creates a .part file each time one composes an email for each attachment that it's opened to confirm it are the correct files to send.

I just confirmed that it also happens in the last version of TB, the 102.10.1. And also it happens in the last version of Betterbird, the same 102.10.1-bb34.

The first time that, while composing an email, I open the attachment, TB or BB asks for what to do, either to save as or to open with. If I try to open it, the first time since installation it does not create such empty .part file. But from the second time on, it always creates one more empty .part file when opening the attachment.

The bug can be reproduced like this:

  • Set content type "Text File" to "Always ask".
  • Start a composition and attach a text file. Double click it.
  • While the prompt "What should Thunderbird do with this file" is up, a <random>.txt.part file appears on the desktop which is removed, when the file is opened.

We didn't test on Linux, but according to the reporter, the files don't get removed.

The opening of the attachment happens here via the uriloader:
https://searchfox.org/comm-central/rev/6d66ffe926d22f3a1568eccd4aa73472ec3e3ad4/mail/components/compose/content/MsgComposeCommands.js#9184-9194
Note that the second parameter in the call true is incorrect, should likely be Ci.nsIURILoader.IS_CONTENT_PREFERRED. Changing that doesn't resolve the issue.

The uri used for the channel is a file:// uri since the TB compose window just stores references to future attachments:

Olli, why does uriLoader.openURI() create a temporary file with .part extension on the desktop? If anything, this should go to a temp directory. It's surprising it needs a temp file in the first place.

We noted that the issue is reported for TB 102 and it fact it doesn't happen in TB 91. So Alice, can you please find the regression, likely looking for an M-C regression here:

STR:
Start TB, compose a new message, add a text file attachment (drag onto the compose window).
In the settings, configure "Text File" to "Always ask", so it doesn't open the file directly.
Double click the attachment. While the "What should Thunderbird do with this file" dialog is up, check the desktop. The bug is that a file with .txt.part appears on the desktop.

Flags: needinfo?(smaug)
Flags: needinfo?(alice0775)

Thank you, Alice, this is fantastic.

So reading the Mozilla 91 code, the files were downloaded to the temp directory, at least for Windows and Linux:
https://searchfox.org/mozilla-esr91/rev/f3f439e007bdd4b5b1c2ba05ca706b68563413b2/uriloader/exthandler/nsExternalHelperAppService.cpp#329
Note that this code is in the else-branch of #ifdef XP_MACOSX.

Nowadays, at least in TB with NS_PREF_DOWNLOAD_FOLDERLIST "browser.download.folderList" a value 0 (NS_FOLDER_VALUE_DESKTOP), the files go to the desktop on all platforms:
https://searchfox.org/mozilla-central/rev/3563da061ca2b32f7f77f5f68088dbf9b5332a9f/uriloader/exthandler/nsExternalHelperAppService.cpp#211
unless pref browser.download.start_downloads_in_tmp_dir is set to true (false in TB by default):
https://searchfox.org/mozilla-central/rev/3563da061ca2b32f7f77f5f68088dbf9b5332a9f/uriloader/exthandler/nsExternalHelperAppService.cpp#204
Setting the pref to false indeed avoids the file on the desktop.

Gijs, is there any harm in setting pref browser.download.start_downloads_in_tmp_dir to false for TB permanently? If so, another option would be just to set the pref temporarily during the call described in comment #14.

@Olli, sorry about the noise, wrong NI.

Flags: needinfo?(smaug) → needinfo?(gijskruitbosch+bugs)

I think that question is better asked of the Thunderbird people. Everything is a trade-off, and the .part files should not persist (if they do, something is going wrong with the "download", which is also a question for the TB folks). There are 100+ comments about the relative merits of that pref in bug 1738574.

Flags: needinfo?(gijskruitbosch+bugs)

Excellent, Gijs, many thanks. Wow, such a long bug. We'll do some reading and come up with a solution that is better suited to mail clients.

Just for the record, with browser.download.start_downloads_in_tmp_dir at false, on Linux the .part files don't get removed from the desktop. They do get removed on Windows. TB doesn't nothing special other than calling the uriloader (see comment #14), unless that calls into https://searchfox.org/comm-central/rev/6d66ffe926d22f3a1568eccd4aa73472ec3e3ad4/mail/modules/AttachmentInfo.sys.mjs#145 and something goes wrong there.

Flags: needinfo?(mkmelin+mozilla)

Thanks for your answer, people of BB.

I just re-confirmed that the bug happens:

  • If one marks the option "Do this automatically for files like this from now on" and then opens it.
    If you don't mark this option when opening an attachment while composing an email, then the .part file appears when the options box pops up for asking what to do with the attachment (whether to save as or to open with), but it disappears once you choose to open it.

  • Also, if you choose to save as, either, marking or not the option to "Do this automatically for files like this from now on" it also creates the .part files.

I attach 5 short videos where it is clearly shown this behaviour.

I have used BB for these tests and pref browser.download.start_downloads_in_tmp_dir is set to true in my case.

I have the same bug on Linux and Windows using the latest Thunderbird version 102.12.0, but I have this issue for over a year.

Duplicate of this bug: 1854110
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: