395053 - File , Open File insists on opening a file from the Firefox installation directory

Status: RESOLVED FIXED

(Firefox :: Menus, defect, P4)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090508 Minefield/3.0a8pre ID:2007090508

repro:
Open FF
Go to File -> Open File (ctrl+O)

result:
the filepicker open in the installer directory.
If you change it by going to another directory, the next time you ctrl+o it's back the the installer directory again

This is most likely caused by the checkin for Bug 308073 or Bug 393247

Comment 1

[Peter van der Woude [:Peter6]]

my bad, guessing wrong

regressionwindow:
works in 20070828_1648_firefox-3.0a8pre.en-US.win32
fails in 20070828_1746_firefox-3.0a8pre.en-US.win32

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1188344880&maxdate=1188348359&cvsroot=%2Fcvsroot

-> Bug 240644

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> the filepicker open in the installer directory.
> regressionwindow:
> works in 20070828_1648_firefox-3.0a8pre.en-US.win32
> fails in 20070828_1746_firefox-3.0a8pre.en-US.win32

To Peter van der Woude(bug opener):

Same question as Bug 394209 Comment #12.
Offering of "Current directory"(= usually program directory) when MS Win is a result of intentional change by Bug 240644 around 7/28.
Please read answer by Gavin Sharp in Bug 394209 Comment #13.

Problem of Bug 394209 still remain? (lastDir is set to non-existent directory)
Or you are talking about phenomenon of offering of "Current Directory" when browser.download.dir is set to non-existent directory?
Or you are saying "offering of current directory is wrong"?

Comment 3

[Peter van der Woude [:Peter6]]

(In reply to comment #2)
> (In reply to comment #0)
> > the filepicker open in the installer directory.
> > regressionwindow:
> > works in 20070828_1648_firefox-3.0a8pre.en-US.win32
> > fails in 20070828_1746_firefox-3.0a8pre.en-US.win32
> 
> To Peter van der Woude(bug opener):
> 
> Same question as Bug 394209 Comment #12.
> Offering of "Current directory"(= usually program directory) when MS Win is a
> result of intentional change by Bug 240644 around 7/28.
> Please read answer by Gavin Sharp in Bug 394209 Comment #13.
> 
> Problem of Bug 394209 still remain? (lastDir is set to non-existent directory)
> Or you are talking about phenomenon of offering of "Current Directory" when
> browser.download.dir is set to non-existent directory?
> Or you are saying "offering of current directory is wrong"?
> 
I'd say offering the user to download / save /open stuff into the directory where Firefox is installed is wrong and should never happen.

This bug is slightly different from Bug 394910.
Here FF doesn't care where you open a file from, the next time you want to open a file the filepicker opens in the installation directory again.

For win2k/XP the default should be User/My Documents/

Comment 4

[V. Korn]

Maybe it should open last used folder?
It's very irritating when you upload a bunch of files (photos, etc) and browser don't want to remember last used folder.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> This bug is slightly different from Bug 394910.
> Here FF doesn't care where you open a file from, the next time you want to open
> a file the filepicker opens in the installation directory again.

> I'd say offering the user to download / save /open stuff into the directory
> where Firefox is installed is wrong and should never happen.
> For win2k/XP the default should be User/My Documents/

Intentional change by Bug 240644(offering of current directory) is for MS Win only, and it occurs only when invalid directory is put in lastDir(or dir) or directory in lastDir(or dir) is not exist any more(e.g. \\XXX\YYY, and server of \\XXX is removed).
And offered directory is not install directory, "current directory", although "current directory" is usually set to install directory.

To Peter van der Woude(bug opener):
Please isolate problems of (a) Bug 394209 : wrong value in lastDir(or dir), (b) Bug 394910 : wrong use of lastDir/dir, (c) "offering of current directory" when wrong value in lastDir/dir, (d) "offering of current directory" when directory in lastDir/dir is not exist any more.
And please note that "offering of current directory" is fall back when error of non-existent directory, never be offering of default directory.

Comment 6

[WADA:World Anti-bad-Duping Agency]

FYI.
In short-cut of MS Win, field name for "current directory" is "work(ing?) folder".
And, when calling user program, CD <Working_Directory> & CALL <program_directory>\program.exe is usual operation.
So "offering of 'work folder' as fall back directory" is proper way, from point of programing view.

Please note that I'm not opposite to your request for "kinder/convenient fall back directory".

Comment 7

[:Gavin Sharp [email: [e-mail]]]

In the File->Open case we don't pass a lastDir (mDisplayDirectory == null), so we relied on the default being "last directory". This changed due to the patch for bug 240644. Having to keep track of the last directory ourselves (using a pref, I guess) really sucks...

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Although I guess that was backed out now... so this should be fixed.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> so we relied on the default being "last directory"

File->Open case looks to use registry of OpenSaveMRU\* / OpenSaveMRU\<ext> when MS Windows.
Following is test result of "File->Open Saved Message" case of Thunderbird.
(1) 8/29 build,9/05 build(patch for Bug 240644 is applied)
    Proposed directory=Work Folder=Current Directory=usually Program directory
(2) 8/22 build,8/27 build(patch for Bug 240644 is not applied yet)
    Proposed directory=$TXT (latest one in my MRUList in OpenSaveMRU\eml).
    When I renamed $TXT to Z$TXT, proposed directory became "My Documents".
Sorry for my misunderstanding about "File->Open" case. 
Because patch for bug 240644 has been backed out, I also think problem when "File->Open" won't occur.

By the way, final fall back directory for download/save looks to be "Work Folder"="Current Direcotry"=usually install folder, even before(and after back out of) patch for Bug 240644.
When "Save As" and "Attach" of Thunderbird with following settings, "Work Folder" was offered as directory for save/attach by all of Thunderbird trunk 8/22, 8/27, 8/29 and 9/05 builds, in both of (Case-A) and (Case-B).
("Save As" uses Download Manager) 
(Case-A) All path related settings is non-existent directory  
> user_pref("browser.download.dir", "\\\\AAA\\AAA");
> user_pref("browser.download.downloadDir", "\\\\BBB\\BBB");
> user_pref("mail.compose.attach.dir", "\\CCC\\CCC");
> user_pref("messenger.save.dir", "\\\\DDD\\DDD");
(Case-B) No above path related settings (just after profile creation)

Comment 10

[WADA:World Anti-bad-Duping Agency]

(Note on my "final fall back directory" in previous comment)
"Final" means when last used directory(latest one in MRUList) is also non-existent.
Before patch for Bug 240644, last used directory was offered when all of xxx.dir is non-existent one, if last used directory exists.
But aftr patch for for Bug 240644, "Working Folder" was offered even when last used directory exits. This is another regression for some users, but it'll be resolved by back out of the patch.

Sorry for confusing comment and spam.

Comment 11

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090606 Minefield/3.0a8pre ID:2007090606

The backout of Bug 240644 fixed the problems:
1) it defaults to user/my documents/
2) it remembers which folder i opened from last time.

Can this bug be closed or does it need a patch after the relanding of Bug 240644 ?

Comment 12

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #11)
> Can this bug be closed or does it need a patch after the relanding of Bug 240644 ?

As I wrote in Bug 240644 Comment #25 and Bug 240644 Comment #42, original problem of Bug 240644(hang/freeze/loop) itself had been resolved by patch for Bug 303675. So I think there is no need to re-land new patch Bug 240644.
Please watch Bug 240644 for a while, before close this bug.
Anyway, sorry for my confusion and misunderstanding.

Comment 13

[Peter van der Woude [:Peter6]]

No problem
We'll wait and see.

Comment 14

[Mike Connor [:mconnor]]

Not going to continue to block on this.  If you disagree with this decision, please renominate with reasons why we can't ship with this in final

Comment 15

[WADA:World Anti-bad-Duping Agency]

There seems to be no plan of next pacth for bug 240644, even though status of bug 240644 is still REOPENED.
Closing this bug. Sorry for late close.