when opening a file from the Download Manager (nsILocalFile::launch on Windows), the working directory is set to the Firefox directory

RESOLVED FIXED in mozilla15

Status

()

Core
XPCOM
RESOLVED FIXED
13 years ago
5 years ago

People

(Reporter: Bartosz Piec, Assigned: bbondy)

Tracking

Trunk
mozilla15
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

After downloading a file and clicking 'Open' on it in Download Manager, it is
opened with a working directory set as a Firefox main directory. When it is i.e.
self-extracting archive, files will be extracted to this directory and can
overwrite some important Firefox files.

Reproducible: Always

Steps to Reproduce:
1. Download some self-extracting archive, i.e. this:
ftp://ftp.3com.com/pub/nic/3c59x/win2k59x.exe
2. Go to Download Manager
3. Find this file and click an 'Open' link
4. (if you downloaded the above file) Agree to the license

Actual Results:  
In Firefox directory there are extracted files (in the above example two files:
EL59X.SYS and NETEL59X.INF). I think that this is caused by setting working
directory for launched file to the Firefox directory.

Expected Results:  
Files should have been extracted to a directory where the file was downloaded
(so the working directory should be set to this directory).

Comment 1

13 years ago
Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050418 Firefox/1.0+
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

12 years ago
*** Bug 296396 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Assignee: bugs → nobody
Severity: major → normal
QA Contact: aebrahim-bmo-507 → download.manager
(Reporter)

Comment 4

12 years ago
This bug is still not fixed. It is present both in Fx 1.0.7 (Mozilla/5.0
(Windows; U; Windows NT 5.1; pl-PL; rv:1.7.12) Gecko/20050919 Firefox/1.0.7) and
in Fx 1.5 Beta 1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050908 Firefox/1.4)

Comment 5

10 years ago
This bug is still present in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

I find this bug somewhat vexing when running executables such as Blizzard Entertainment's Bittorrent downloaders.  The downloaders save files in their current working directory, which ends up being the Firefox directory.  Once the download has completed, the downloader exits, but the downloaded file is nowhere to be found, until I remember this bug.

I have resorted to always using Open Containing Folder on executables and then double-clicking on the file in Windows Explorer so as to get the proper working directory.
Product: Firefox → Toolkit

Updated

7 years ago
Duplicate of this bug: 646486

Comment 7

5 years ago
Although this is not a bug, but can be annoying for non experienced users.
I have stumbled on it developing a self extracting installer.
I have created a small program in C (working on workaround for my application):

********************PROGRAM START***********************************
#include <stdio.h>
#include <stdlib.h>

#include <Windows.h>
#include <Winbase.h>
#include<wchar.h>
#include<locale.h>

int main()
{
    //setlocale(LC_CTYPE, "utf-8");
    setlocale( LC_ALL, ".utf-8" );

    const int BUFFER_LEN = 1000;
    wchar_t * dirBuffer;
    dirBuffer = (wchar_t*) malloc (sizeof(wchar_t)*BUFFER_LEN);
    GetCurrentDirectoryW(BUFFER_LEN, dirBuffer);
    wprintf(L"\nCurrent directory:%s", dirBuffer);

    FILE * outFile;
    wchar_t * FILE_NAME = L"C:\\ffproblem.txt";
    outFile = _wfopen(FILE_NAME, L"w");
	char * convertedString;

	convertedString = (char*) malloc (sizeof(char)*BUFFER_LEN);


    //Doc: http://msdn.microsoft.com/en-us/library/dd374130%28VS.85%29.aspx
    WideCharToMultiByte(CP_UTF8, 0,
                        dirBuffer, wcslen(dirBuffer),
                        convertedString,
                        BUFFER_LEN, NULL, NULL);

    printf("\nConverted string:%s", convertedString);
	fprintf(outFile, "\nCurrent directory:%s", convertedString);

	fclose(outFile);

	wprintf(L"\nFile written");
	free (convertedString);
	free(dirBuffer);

    return 0;
}
********************PROGRAM END***********************************

Which when compiled to exe will create a file C:\ffproblem.txt with working directory of the exe file, while started.
The issue is appearing even when file is being 'downloaded' from local disk. Exe file should be started from download manager of firefox and then working directory for exe will be installation directory of the firefox, which is an essence of the issue at hand.

Compiled exe file of the programm can be found at: http://vassiliev.com.ua/FireFoxProblemProof.exe
Though I can imagine you will be afraid to run exe files from other sources, hence - source of the program above.
Also for testing purposes there is a rar sfx archive (http://vassiliev.com.ua/config.exe) which will show the run directory once executed. You also can create any sfx RAR archive and use it for testing.

To be fair this issue is also present in Opera (tested on 11th version), though IE and Chrome (current versions) are working as expected, providing working directory for the executed programm as one where it was downloaded.

Comment 8

5 years ago
Created attachment 623469 [details]
RAR SFX archive, which will show startup directory once executed.
The download manager just calls nsLocalFileWin::Launch - this ends up calling AsyncLocalFileWinOperation::Launch, which calls ShellExecuteExW with lpDirectory==NULL, which means "current working directory".

We could pass in the path to the parent directory in the lpDirectory parameter, but that would require some munging, since AsyncLocalFileWinOperation only holds on to the path to the file to be launched.
Component: Download Manager → XPCOM
Product: Toolkit → Core
QA Contact: download.manager → xpcom
Summary: Opening a file from Download Manager causes setting a working directory as a Firefox directory → when opening a file from the Download Manager (nsILocalFile::launch on Windows), the working directory is set to the Firefox directory
(Reporter)

Comment 10

5 years ago
IMO the best solution would be to pass the directory in which the launched file is located.
(Assignee)

Updated

5 years ago
Component: XPCOM → Widget: Win32
QA Contact: xpcom → win32
(Assignee)

Updated

5 years ago
Assignee: nobody → netzen
(Assignee)

Updated

5 years ago
Component: Widget: Win32 → XPCOM
QA Contact: win32 → xpcom
(Assignee)

Comment 11

5 years ago
Created attachment 623536 [details] [diff] [review]
Patch v1.
Attachment #623536 - Flags: review?(jmathies)

Comment 12

5 years ago
Comment on attachment 623536 [details] [diff] [review]
Patch v1.

Review of attachment 623536 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/io/nsLocalFileWin.cpp
@@ +256,5 @@
> +
> +        // Use the directory of the file we're launching as the working
> +        // directory.  That way if we have a self extracting EXE it won't
> +        // suggest to extract to the install directory.
> +        WCHAR workingDirectory[MAX_PATH + 1] = { 'L\0' };

oops - 'L\0'

@@ +258,5 @@
> +        // directory.  That way if we have a self extracting EXE it won't
> +        // suggest to extract to the install directory.
> +        WCHAR workingDirectory[MAX_PATH + 1] = { 'L\0' };
> +        wcsncpy(workingDirectory,  mResolvedPath.get(), MAX_PATH);
> +        if (PathRemoveFileSpecW(workingDirectory)) {

Looks like this should never fail, so lets add an NS_WARNING if it does.
Attachment #623536 - Flags: review?(jmathies) → review+

Comment 13

5 years ago
Does this change the working directory for the application? If so, we'll also need to reset it back. I don't think it does, but we should confirm.
(Assignee)

Comment 14

5 years ago
Created attachment 623638 [details] [diff] [review]
Patch v2.

> Does this change the working directory for the application? If so, we'll also 
> need to reset it back. I don't think it does, but we should confirm.

I'm pretty certain it does not but I'll verify before landing.
Attachment #623638 - Flags: review+
(Assignee)

Updated

5 years ago
Attachment #623536 - Attachment is obsolete: true

Comment 15

5 years ago
At last I have made Firefox compile and I have checked the change of the local directory by the patch and confirm that current directory stays the same as expected.
Not really sure how to submit testing patches, so please find below a code I have used. It's a bit rough, but does it's thing.

*******************************START***************************************
// Use the directory of the file we're launching as the working
        // directory.  That way if we have a self extracting EXE it won't
        // suggest to extract to the install directory.
        WCHAR workingDirectory[MAX_PATH + 1] = { L'\0' };
        wcsncpy(workingDirectory,  mResolvedPath.get(), MAX_PATH);
        if (PathRemoveFileSpecW(workingDirectory)) {
          seinfo.lpDirectory = workingDirectory;
        } else {
          NS_WARNING("Could not set working directory for launched file.");
        }

        if (ShellExecuteExW(&seinfo)) {
            GetCurrentDirectory(MAX_PATH + 1, currentDirectory);
            MessageBoxW(NULL, currentDirectory, L"After open file1.", MB_OK);
            return NS_OK;
            }

        GetCurrentDirectory(MAX_PATH + 1, currentDirectory);
        MessageBoxW(NULL, currentDirectory, L"After open file2.", MB_OK);

*******************************END***************************************
Hope it will save a couple of minutes.
Thank you Gavin, Brian and Jim for your help. I did not expect this to be so fast.
(Assignee)

Comment 16

5 years ago
> vaal12@yandex.ru wrote:
> I have checked the change of the local directory by the patch and confirm 
> that current directory stays the same as expected.

Thanks for double verifying this, try results looks good so pushed to inbound.  
http://hg.mozilla.org/integration/mozilla-inbound/rev/fd33193a3063
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/fd33193a3063
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 18

5 years ago
This change made to the central repository and works as expected.
Thank you everyone.
You need to log in before you can comment on or make changes to this bug.