1743543 - Failed to save a downloaded file via Windows RDP on UNC path like "\\tsclient\C\dir"

Status: RESOLVED DUPLICATE of bug 1731049

(Toolkit :: General, defect)

Description

[Aleksey F.]

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

Steps to reproduce:

I tried to download and save an attachment (*.docx) from an email web client onto a remote drive connected by Windows RDP under UNC path like "\tsclient\C\dir", where 'D' is the drive letter.

Actual results:

Save failed, but download completed.

Expected results:

Save completed, as this accomplished by Chromium engine, or when a local drive is selected as a destination.

Comment 1

[Aleksey F.]

Clarification: the path is like "\\tsclient\C\dir".

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Alex Cornestean]

Hello,

I’m from QA and I’m attempting to reproduce the issue in order to confirm it, however I’m not entirely sure on how to proceed.

Would you mind providing some more detailed steps to reproduce?

Comment 5

[Aleksey F.]

Preconditions

1. There is a remote Windows-based system (denoted as w-host) accessible via RDP
2. When connecting to w-host via RDP, at least one local drive is attached to w-host (denoted as ts-drive) via the path like \\tsclient\<L>, where <L> is the local drive letter
3. In Mozilla Firefox browser, under about:preferences, the Always ask you where to save files option is on
4. There is a remote file with a known URL accessible to download from a web page

Method

1. connect to a remote Windows-based system via RDP
2. open a web page with URL pointing to a remote file for downloading
3. download the file:
   3.1 click on that URL to open a save file dialog, which is entitled like "Opening <remote resource title>"
   3.2 in the save file dialog, choose the "Save file" option and click "Ok"
   3.3 in the next dialog entitled "Enter name of file to save to...", choose a directory under ts-drive
   3.4 click "Save"

Result

Download succeeded, but the file failed to save.
Exact message description under the downloaded item: "Failed"

Tested method implementations

1. connect to a remote Windows-based system via RDP
w-host: Windows 10 Corp LTSC, 10.0.17763.914
local systems:
a) Windows Server 2003
RDP client: 6.0.6001
RDP version: 6.1
b) Windows 7 Pro
RDP client: 6.3.9600
RDP version: 8.1

2. open a web page with URL pointing to a remote file for downloading
GMail email web client was used.
Searched for "has:attachment docx"
-> chose some email message
-> clicked "Download" on an attachment

3.3 in the next dialog entitled "Enter name of file to save to...", choose a directory under ts-drive
The directory under ts-drive chosen:
a) Z:\tmp => \\tslient\Z\tmp
b) C:\temp => \\tslient\C\temp
Short pathnames allowed avoiding possible fails caused by the max length requirement to a pathname in Windows-based systems.

Checking for the method correctness

Chromium-base web browser were used: Chrome, Yandex.Browser

Comment 6

[Alex Cornestean]

Hello and thank you for the additional info !

While attempting to use/set up the Windows Remote Desktop Connection app to proceed with the steps to reproduce the issue I’ve noticed the Remote Desktop setting from the System Settings was turned off with no possibility to turn it on as it’s managed by my organization.

Unfortunately there is no workaround for this and I cannot confirm the issue.

Comment 7

[:Gijs (away/busy until Mar 10)]

I think I just fixed this in Firefox 96, in bug 1731049. Could you try with Firefox beta ( https://beta.mozilla.org/ ) and confirm if it works for you with that build?

Comment 8

[:Gijs (away/busy until Mar 10)]

(In reply to :Gijs (he/him) from comment #7)

I think I just fixed this in Firefox 96, in bug 1731049. Could you try with Firefox beta ( https://beta.mozilla.org/ ) and confirm if it works for you with that build?

Oh, and I just realized, Firefox 95 (released week before last) also got this patch, so if you update your regular Firefox, hopefully this is fixed?

Comment 9

[Aleksey F.]

I tested Firefox 95.0.2 and confirmed that the bug was fixed.

Comment 10

[:Gijs (away/busy until Mar 10)]

(In reply to Aleksey F. from comment #9)

I tested Firefox 95.0.2 and confirmed that the bug was fixed.

Perfect! Thanks again for the report, and apologies that this broke - but glad it's fixed now. :-)