Closed Bug 1601905 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: XPCOM, defect, P1)

Product:
Core
Component:
XPCOM
Version:
68 Branch
Platform:
Unspecified
Windows
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla73
Tracking Flags:
Tracking Status
thunderbird_esr68 72+ verified
firefox-esr68 72+ verified
firefox71 --- wontfix
firefox72 --- verified
firefox73 --- verified
firefox74 --- verified

People

(Reporter: a.sukharichev, Assigned: toshi)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [regression tb68.3.0])

Attachments

(1 file, 2 obsolete files)

Bug 1601905 - Add quotes for a path including whitespaces in ShellExecuteWithIFile. r=aklotz
47 bytes, text/x-phabricator-request
Details | Review

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

Keywords: regression
Summary: 68.3.0 can`t open pdf with spaces in name → 68.3.0 can`t open attachments with spaces in name

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Flags: needinfo?(vseerror)
tracking-thunderbird_esr68: --- → +
Component: Untriaged → OS Integration
Whiteboard: [regression tb68.3]

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

OS: Unspecified → Windows

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

status-thunderbird_esr68: --- → affected
Flags: needinfo?(vseerror) → needinfo?(mkmelin+mozilla)
Priority: -- → P1
Regressed by: 1588975
Whiteboard: [regression tb68.3] → [regression tb68.3.0]
Has Regression Range: --- → yes

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.

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

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.

Flags: needinfo?(tkikuchi)

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).

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".

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.

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.

Flags: needinfo?(tkikuchi)

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

Assignee: nobody → tkikuchi
Component: OS Integration → XPCOM
Product: Thunderbird → Core
Version: 68 → 68 Branch
Flags: needinfo?(mkmelin+mozilla)

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.

Blocks: 1604287

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

Flags: needinfo?(tkikuchi)

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)

Flags: needinfo?(tkikuchi)

[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

See Also: → 1605131
Pushed by dluca@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/529caf75be5d
Add quotes for a path including whitespaces in ShellExecuteWithIFile.  r=aklotz

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

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox73: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
Flags: in-testsuite+

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 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
Attachment #9117392 - Flags: approval-mozilla-esr68?

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

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 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
Attachment #9117558 - Flags: approval-mozilla-beta?

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.

Attachment #9117558 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

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..

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?

OK. Just responded to comment 37..
Blessings

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.

(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

Flags: needinfo?(aryx.bugmail)

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

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.

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

Summary: 68.3.0 can`t open attachments with spaces in name → 68.3 can`t open attachments with spaces in name
Summary: 68.3 can`t open attachments with spaces in name → 68.3.x can't open attachments with spaces in name
Attachment #9117558 - Attachment is obsolete: true

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.

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

Flags: needinfo?(tkikuchi)

(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).

Flags: needinfo?(tkikuchi)

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

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.

Attachment #9117392 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Attachment #9117392 - Attachment is obsolete: true

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

Flags: needinfo?(tkikuchi)

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

Flags: needinfo?(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.

status-firefox72: wontfix → affected
Flags: needinfo?(jcristau)

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.

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

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!

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

Flags: needinfo?(tkikuchi)

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
Attachment #9117558 - Flags: approval-mozilla-release?
Attachment #9117558 - Attachment is obsolete: false

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

Attachment #9117558 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9117558 - Attachment is obsolete: true
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

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!

Status: RESOLVED → VERIFIED
status-firefox72: fixed → verified
status-firefox73: fixed → verified
status-firefox74: --- → verified
status-firefox-esr68: fixed → verified
Flags: qe-verify+

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?

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

(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.

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.

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

Attachment

General

Creator:
Created:
Updated:
Size: