1601905 - 68.3.x can't open attachments with spaces in name

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P1)

Description

[Alex]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Im Trying to open pdf file with space (-es) in its name from recieved email attachment with thunderbird 68.3.0.

Actual results:

If Thunderbird version equal to 68.3.0, any PDF viewer (Acrobat reader, Foxit Reader) displays the message "file "_filename_part_after_Space.pdf" could not be opened" and\or "file not found". If Thunderbird ver. 68.2.x or lower, it opens such files successfuly. If I forward this file without changes, TB 68.3 fails to open it with the same result. If I rename the file, and remove space from its name, it opens successfuly in any version, including 68.3. Other file types (txt, png) doesn`t affected. Temporary copies of files in system temp folder appears in both cases, so looks like TB 68.3 makes all things right, but transfer the URL of file with spaces to pdf application incorrectly.

Expected results:

File with any name should be opened successfuly

Comment 3

[Matt]

I am confirming the bug, I am seeing the exact same issue.

Regression caused by bug 1588975 perhaps. It is the only shell command modification I can see in the platform changeset.

Comment 4

[Matt]

Can we get this fixed before you open the floodgate to 60X users Wayne? I think it would be a serious issue for most users as most files these days have spaces.

Comment 5

[Magnus Melin [:mkmelin]]

Not a problem on Linux (as expected if it's a regression from bug 1588975)

Comment 7

[Wayne Mery (:wsmwk)]

Hmm no other regressions filed against bug 1588975.
Who to fix?

Comment 8

[Magnus Melin [:mkmelin]]

Looks like we're calling https://searchfox.org/comm-central/rev/e23955012159e85de5a57d21a27f61f170fc3804/mail/base/content/msgHdrView.js#1999 -> https://searchfox.org/comm-central/rev/e23955012159e85de5a57d21a27f61f170fc3804/mailnews/base/src/nsMessenger.cpp#699 -> https://searchfox.org/comm-central/search?q=OpenAttachment&case=false&regexp=false&path=Service.cpp

Is this both IMAP and POP?

Comment 9

[Alex]

I`ve checked POP access with same result - 68.3.0 failed to open attachments with spaces, BUT please, pay attention to fact, that txt files could be opened successfuly, no matter with, or without spaces.

Comment 10

[Alex]

...and *.xls too could be opened successfuly, no matter with, or without spaces.

Comment 11

[Masatoshi Kimura [:emk]]

Bug 1588975 changed LaunchWithIProcess to ShellExecuteWithIFile: https://hg.mozilla.org/mozilla-central/rev/abcbfdf1a1ef#l2.60

Although LaunchWithIProcess assumes that path is a single argument and quote it automatically, ShellExecuteWithIFile doesn't. So it will fail to open file names that contain spaces.

Comment 12

[roethig_j]

For me it doesn't depend on file type to open. e.g. Acrobad Reader opens the pdf attachment, while GIMP doesn't oden the same file.
Notepad2 opens a txt file, while LibreOffice don't open the same file (attachment).

Comment 13

[Daniel Karwatka]

If it helps, this problem was not in 68.2.2.

You are correct it doesn't depend upon the file contents just that the name contains spaces.

If the file name is "ABC 123.txt", It will try to open file "ABC" and file "123.txt".

Comment 15

[Alex]

Ok, may be it depends on application itself, some of them percept path with spaces correctly, and fold it into to qotes, some doesn`t.

Comment 16

[Toshihito Kikuchi [:toshi]]

Thank you for letting me know. I could reproduce the issue on Firefox Nightly, too. This happens when we open a file having whitespaces with a custom application which considers it as multiple tokens (e.g. Adobe Reader DC). Let me try to use assembleCmdLine.

Comment 17

[Jorg K (CEST = GMT+2)]

Can we move the bug to a Mozilla core component, please.

Comment 18

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile. r=aklotz

A fix for Bug 1588975 replaced the call to LaunchWithIProcess in
nsMIMEInfoWin::LaunchWithFile with the call to ShellExecuteWithIFile to use
mozilla::ShellExecuteByExplorer. This caused a regression that if a filepath
contains whitespaces, we pass it to a target application without quoting it
while the old codepath ShellExecuteWithIFile quoted a path accordingly in
assembleCmdLine.

A proposed fix is to quote a path in the same way as assembleCmdLine does.
This patch also moves assembleCmdLine to an exported header so that we can add
a unittest to cover both of assembleCmdLine and a new function
`assembleSingleArgument. It would be better to refactor these functions in the
future because many lines are duplicated.

Comment 24

[Pascal Chevrel:pascalc]

Toshi, do you have an update on this bug? Do you think we will have a fix we could uplift to 72 and ESR for our January or a 71 dot release? Thanks

Comment 25

[Pascal Chevrel:pascalc]

Nevermind, I see that all the duplicates are for Thunderbird so there is no impact on the 71/72 Firefox schedule (would be good to uplift a fix to ESR though)

Comment 30

[Rolf]

[Bug 1605074] is not exactly a duplicate. Only pdf files are affected by "my" bug. They do not even launch the acrobat reader, just noting happens. Moreover, the bug affects just outgoing emails, pdfs attached to incoming mails do open without any problem. I did not observe, however, that pdfs without space in their name would open in outgoing mails

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/529caf75be5d
Add quotes for a path including whitespaces in ShellExecuteWithIFile.  r=aklotz

Comment 32

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/529caf75be5d

Comment 34

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

A fix for Bug 1588975 replaced the call to LaunchWithIProcess in
nsMIMEInfoWin::LaunchWithFile with the call to ShellExecuteWithIFile to use
mozilla::ShellExecuteByExplorer. This caused a regression that if a filepath
contains whitespaces, we pass it to a target application without quoting it
while the old codepath ShellExecuteWithIFile quoted a path accordingly in
assembleCmdLine.

A proposed fix is to quote a path in the same way as assembleCmdLine does.
This patch also moves assembleCmdLine to an exported header so that we can add
a unittest to cover both of assembleCmdLine and a new function
`assembleSingleArgument. It would be better to refactor these functions in the
future because many lines are duplicated.

Comment 35

[Toshihito Kikuchi [:toshi]]

Comment on attachment 9117392 [details]
Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a regression from Bug 1588975 which was uplifted to ESR68. Given that we already got a high number of duplicate bugs and the regressing scenario is common, this bug has high impact on ESR users.
• User impact if declined: Firefox/Thunderbird cannot open a downloaded file with a non-default application if the file is stored into a path including whitespaces.
• Fix Landed on Version: 73.0a1
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low. This changes add a call to assembleSingleArgument to process a command line string. This change also adds a unittest to make sure assembleSingleArgument behaves the same as assembleCmdLine which is used in the original codepath.
• String or UUID changes made by this patch: None

Comment 36

[Thomas]

Here is an enduser and this is a heavy regression IMHO, no fix in official versions available. Observed since 60.9.1 20191031083309 and upgrade 68.3.1 20191215232630. PDF and DOCX affected for sure:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

Comment 37

[Thomas]

Installed beta 72.0b2 on my pa PC and looks to be not affected. Attachements can be opened again. Call it a Parents Christmas Bug (PCB) if you understand what I mean. ;-)
Happy Christmas 2019 all.

Comment 38

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

A fix for Bug 1588975 replaced the call to LaunchWithIProcess in
nsMIMEInfoWin::LaunchWithFile with the call to ShellExecuteWithIFile to use
mozilla::ShellExecuteByExplorer. This caused a regression that if a filepath
contains whitespaces, we pass it to a target application without quoting it
while the old codepath ShellExecuteWithIFile quoted a path accordingly in
assembleCmdLine.

A proposed fix is to quote a path in the same way as assembleCmdLine does.
This patch also moves assembleCmdLine to an exported header so that we can add
a unittest to cover both of assembleCmdLine and a new function
`assembleSingleArgument. It would be better to refactor these functions in the
future because many lines are duplicated.

Comment 39

[Toshihito Kikuchi [:toshi]]

Comment on attachment 9117558 [details]
Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

Beta/Release Uplift Approval Request

• User impact if declined: Firefox/Thunderbird cannot open a downloaded file with a non-default application if the file is stored into a path including whitespaces.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This changes add a call to assembleSingleArgument to process a command line string. This change also adds a unittest to make sure assembleSingleArgument behaves the same as assembleCmdLine which is used in the original codepath.
• String changes made/needed: None

Comment 40

[Julien Cristau [:jcristau]]

Comment on attachment 9117558 [details]
Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

I'd rather not take this right before the 72 release, let it bake on 73 instead.

Comment 44

[musiquegraeme]

I don't want to spoil the New Year but I have 72.0b2 and I can't open Word, Excel or powerpoint files even if there are no spaces. Adobe pdf files continue to open perfectly. I get error messages about invalid directories and if there are spaces, files not found for the bit(s) after the space..

Comment 45

[Jorg K (CEST = GMT+2)]

Well, this was fixed in mozilla73 and beta uplift to 72 was declined. So why do you think it would work in 72 beta 2?

Comment 46

[musiquegraeme]

OK. Just responded to comment 37..
Blessings

Comment 47

[Jorg K (CEST = GMT+2)]

Well, that comment was just wrong. Frankly, I'm on TB 68.3.1 where the bug is not fixed so far and I've never experienced it despite opening attachments left, right and centre. But it only affects certain applications; I can open PDFs with spaces in their name with PDF XChange Viewer with no problem ... EDIT: And .odt and .doc(x) in LibreOffice (EDIT 2: version 5.4) and images in Windows Photo Viewer.

Comment 48

[Magnus Melin [:mkmelin]]

(In reply to Andrei Ciure[:andrei_ciure] from comment #32)

https://hg.mozilla.org/mozilla-central/rev/529caf75be5d

We'll want this for the next Thunderbird point release. Aryx, please uplift to the THUNDERBIRD_68_VERBRANCH

Comment 49

[Jorg K (CEST = GMT+2)]

You should merge m-esr68 b9ced0dd1026bf43339ecd41b942d19f63ea72c6 (FIREFOX_68_4_0esr_BUILD1) into that branch first.

Comment 50

[Felix B.]

I can actually reproduce the issue with current version of Thunderbird (68.3.1). It currently only occurs with Libre Office 6.2.8.2. Neither MS Office 2010 or 2019, nor Acrobat Reader are affected. Operating system is Windows 10 32bit and 64bit.

The guys from the German Libre Office forum deny that this was a bug from their side? It obviously can't be reproduced with the current development versions from Libre Office as well as on openSuSE Linux operating system.

Comment 51

[Magnus Melin [:mkmelin]]

Yes this is a Mozilla bug. There is a patch that we will land for thunderbird 68.4.

Comment 52

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Push to THUNDERBIRD_68_VERBRANCH: https://hg.mozilla.org/releases/mozilla-esr68/rev/09c165cf667385dde0d4b1293a2fc264dc5f6906

Comment 55

[Jorg K (CEST = GMT+2)]

Push from comment 52 also contains the merge requested in comment #49:
https://hg.mozilla.org/releases/mozilla-esr68/pushloghtml/?changeset=09c165cf667385dde0d4b1293a2fc264dc5f6906

Comment 59

[Terry]

TB 68.3.1 I cannot open any attachment; .pdf, .doc, .xls, .jpg whether file name has spaces or not.
TB is on a W2019 Server users access TB via RDP.
On single user install no issues I have found to date.

Comment 61

[Ryan VanderMeulen [:RyanVM]]

Does this need an ESR68 approval request? Given comment 59, it's not clear we're out of the wood yet, though :\

Comment 62

[Toshihito Kikuchi [:toshi]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #61)

Does this need an ESR68 approval request? Given comment 59, it's not clear we're out of the wood yet, though :\

Yes. A request for ESR is here.

Comment 59 sounds like the same as Citrix issue (bug 1602726).

Comment 63

[Magnus Melin [:mkmelin]]

The fix is only in Thunderbird 68.4.1 (soon to be released)

Comment 65

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9117392 [details]
Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

Fixes a regression from bug 1588975. Approved for 68.5esr.

Comment 66

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/008191a25c12

Comment 70

[Masatoshi Kimura [:emk]]

I think this bug is worth taking in a dot release for 72.

Comment 73

[:Gijs (he/him)]

Can we reconsider this for 72? This is collecting a lot of dupes. :-\

Comment 74

[Julien Cristau [:jcristau]]

I guess. It previously looked like almost all of the dupes were for thunderbird, but if not then let's consider this for 72.0.2.

Comment 75

[GrimDemon]

I confirm that the bug is fixed in Firefox 73 beta. Please think about the patch/new version for Firefox 72 branch. Many people use file handlers and the "open with" function everyday. The presence of this bug means that each file must be saved to disk and then opened in the correct application. This significantly extends the daily work.

Comment 76

[drlellinger]

Can confirm what GrimDemon is saying. Customers from my company are temporarily switching back to IE because of this :D

Comment 78

[[e-mail]]

Our users have a lot of attachments with filenames containing spaces, they couldn't open these attachments in the past month or so, the only solution is to save them to a folder and then open it. Sorry, but this is a major problem for us, so please, fix this bug ASAP (the solution is simple: check if filename has spaces in it, then add double quotes before and after the filename). Thanks!

Comment 79

[Toshihito Kikuchi [:toshi]]

Given that there is no regression report from this change after this was released in Nightly and Beta, I agree to uplift to 72.

Comment 80

[Toshihito Kikuchi [:toshi]]

Comment on attachment 9117558 [details]
Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

Beta/Release Uplift Approval Request

• User impact if declined: Firefox/Thunderbird cannot open a downloaded file with a non-default application if the file is stored into a path including whitespaces. This is a functional regression with a broad impact.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This change adds a call to assembleSingleArgument to process a command line string. This change also adds a unittest to make sure assembleSingleArgument behaves the same as assembleCmdLine which is used in the original codepath.
• String changes made/needed: None

Comment 83

[Julien Cristau [:jcristau]]

Comment on attachment 9117558 [details]
Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile.

regression fix, lots of duplicates, approved for 72.0.2

Comment 84

[Ryan VanderMeulen [:RyanVM]]

Landed on FIREFOX_ESR_68_4_X_RELBRANCH for 68.4.2.
https://hg.mozilla.org/releases/mozilla-esr68/rev/8fb71d4399777dcbe94f9a58ef061d87520a6ab5

Comment 85

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/ad9082423a81

Comment 86

[Daniel Bodea [:danibodea]]

I have attempted to understand this issue and reproduce it. While having Thunderbird v68.3.1 installed, I have sent an attached pdf file that has whitespaces in its name to an email on another client and sent it to my thunderbird client. Then, I attempted opening the PDF with Foxit Reader (when Adobe Acrobat Reader DR is the default one). I have managed to reproduce the issue; the pdf file was not opened and errors that incorrect pdf file names were attempted to be opened.

Furthermore, this exact issue appears fixed in Thunderbird v68.4.1. I will not continue verifying this for Thunderbird, but I will do my best to verify it in Firefox.

I managed to reproduce the issue in Nightly v73.0a1 from 2019-12-18 and Release v72.0.1 and ESR v68.4.1esr using these steps:
Opened a yahoo mail web client in the browser and attempted to open a PRD file with whitespaces in its name, attached from a mail. The PDF would not open correctly and errors regarding corrupted files are being displayed.

I managed to verify the fix using the same steps on the following versions:

• Nightly v74.0a1 from 2020-01-20
• Beta v73.0b7
• Release v72.0.2
• ESR v68.4.2esr

I deem this bug verified!

Comment 88

[Mithat Bozkurt]

I use Thunderbird with version 91.3.0 (64 bit) on Ubuntu 20.04.3 LTS. I still have a same problem. I don't know what should i do to get solution. Either adding this comment or create a new bug?

Comment 89

[Matt]

As this bug was fixed, commenting here is basically doing nothing, except email me and everyone associated with the bug from years ago. No one is going to be reopening it this far down the track for a different operating system. So a new bug referencing this history would be the way to go.

Make your use of Linux and the distribution and source of the build you are experiencing issues with clear in the initial report. This is quite important in Linux as many distributions build customised Thunderbird versions, so knowing which up front can be helpful

Comment 90

[martin651]

(In reply to Mithat Bozkurt from comment #88)

I use Thunderbird with version 91.3.0 (64 bit) on Ubuntu 20.04.3 LTS. I still have a same problem. I don't know what should i do to get solution. Either adding this comment or create a new bug?

I have the same issue, but I believe the problem is not on Thunderbird's side. Thunderbird saves the files somewhere in /tmp/mozilla_xxx and in Ubuntu 20.04 it seems some apps don't have enough rights to open these files from that place. Just try to open the files directly from that place to check if this is also the root cause on your side.

Comment 91

[martin651]

I use Thunderbird with version 91.3.0 (64 bit) on Ubuntu 20.04.3 LTS. I still have a same problem. I don't know what should i do to get solution. Either adding this comment or create a new bug?

Just a further comment. In my case it was the fact that the app (LibreOffice) was installed as a Snap package. And Snap packages don't have access to /tmp. So installing such apps with deb packages helps.