1103607 - Firefox does not remember the last directory when saving files

Status: UNCONFIRMED

(Toolkit :: Downloads API, defect)

Description

[hawran]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141013200257

Steps to reproduce:

1. Clicked on a link with a file to download.
2. Chose a required action - Save file ... 


Actual results:

A "Enter name of file to save to ..." box opened, offering a name of a file and - a directory to save a file to - and that directory was picked randomly.
I had no idea according to what rule it had been chosen.

All files were of the same type (extension).



Expected results:

I would expect firefox keeps offering the last directory used (to save!).

At least for all files saved during a session (=durring one app's run), if it is not possible to keep history for differrent types of saved files durring a session.

-------------------------------
System Info:
========
Ubuntu 14.04.1 LTS
---
Firefox Version: 33.0
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Multiprocess Windows: 0/2

Comment 1

[:Gijs (he/him)]

Firefox should be remembering the last directory you saved files in on a per-site/domain basis. Is that not the behaviour you're seeing?

Comment 2

[hawran]

(In reply to :Gijs Kruitbosch from comment #1)
> Firefox should be remembering the last directory you saved files in on a
> per-site/domain basis. Is that not the behaviour you're seeing?

Wow, per-domain?
However, I downloaded files from one server (still the same address within the address box).

Comment 3

[:Gijs (he/him)]

Paolo?

Comment 4

[hawran]

I's just crossed my mind:
is it possible that firefox both "recognises and remember" downloaded files via some MIME stuff, not from actual files's  extensions and web's authors have made mistakes when "tagging" (or whatever) those files?
Just my two cents ...

Comment 5

[:Gijs (he/him)]

(In reply to hawran from comment #4)
> I's just crossed my mind:
> is it possible that firefox both "recognises and remember" downloaded files
> via some MIME stuff, not from actual files's  extensions and web's authors
> have made mistakes when "tagging" (or whatever) those files?
> Just my two cents ...

Not just possible, but a long-standing issue. See discussion on e.g. bug 332690 and deps.

Comment 6

[hawran]

(In reply to :Gijs Kruitbosch from comment #5)
> (In reply to hawran from comment #4)
...
> 
> Not just possible, but a long-standing issue. See discussion on e.g. bug
> 332690 and deps.

Oh, I see.

Comment 7

[:Paolo Amadini]

Hello, sorry for getting back late on this specific bug report. Since this issue was reported, there have been fixes in the code area that controls the last location used, in particular bug 1115248, and possibly a follow-up in bug 1196144, that doesn't seem directly related but is worth considering.

If this is still an issue in the release version, can you try installing the latest Beta version and see if the problem has been resolved?

Comment 8

[hawran]

Sorry for the delay, my findings are as follows:

I've just tried to download a couple of different files (at least regarding file extensions):
txt
m3u
rar
sfv
wav
cfg
vbs
php
bat
md
7z
zip
exe
local
rtf

I've chosen a directory for the first file and firefox has NOT remembered the target directory for all files.

For me, the issue is still open.

PS Application Basics
---------------------
Name: Firefox
Version: 48.0
Build ID: 20160728204513
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
OS: Linux 3.13.0-92-generic x86-64
Multiprocess Windows: 0/1 (Disabled)
Safe Mode: false
...

Comment 9

[:Gijs (he/him)]

(In reply to hawran from comment #8)
> Sorry for the delay, my findings are as follows:
> 
> I've just tried to download a couple of different files (at least regarding
> file extensions):
> txt
> m3u
> rar
> sfv
> wav
> cfg
> vbs
> php
> bat
> md
> 7z
> zip
> exe
> local
> rtf
> 
> I've chosen a directory for the first file and firefox has NOT remembered
> the target directory for all files.
> 
> For me, the issue is still open.
> 
> PS Application Basics
> ---------------------
> Name: Firefox
> Version: 48.0
> Build ID: 20160728204513
> User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101
> Firefox/48.0
> OS: Linux 3.13.0-92-generic x86-64
> Multiprocess Windows: 0/1 (Disabled)
> Safe Mode: false
> ...


If you try this on a clean profile, do you see a different behaviour? ( https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles - you can keep your existing profile when you create and test with a separate one )

(NB: there might still well be a Firefox problem if this happens on your current profile and not on a new one, but it helps us to figure out where to look for one, esp. because it seems to work for me...)

Comment 10

[hawran]

(In reply to :Gijs Kruitbosch (PTO recovery mode) from comment #9)
> If you try this on a clean profile, do you see a different behaviour? (
> https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-
> profiles - you can keep your existing profile when you create and test with
> a separate one )
> 
> (NB: there might still well be a Firefox problem if this happens on your
> current profile and not on a new one, but it helps us to figure out where to
> look for one, esp. because it seems to work for me...)


Hi,
I've just tried it on a clean profile and it seems to be working now.
The rest is up to you...

Comment 11

[:Gijs (he/him)]

I'm guessing your content-prefs.sqlite file in your main profile is corrupt. You could:

0) start firefox with your normal profile
1) open help > Troubleshooting information
2) click the button next to "Profile Folder"
3) find the content-prefs.sqlite file in the files/nautilus/finder window that shows up
4) close all copies of firefox
5) move content-prefs.sqlite to e.g. content-prefs-old.sqlite
6) restart firefox

and then it should work in your old profile. I don't know if there are more things we can do to detect content-prefs.sqlite breakage. Paolo?

Comment 12

[:Paolo Amadini]

(In reply to :Gijs Kruitbosch from comment #11)
> I don't know if there are more things we can do to detect content-prefs.sqlite breakage. Paolo?

If we are unable to write to the database because it's corrupt, there is little we can do save for erasing it entirely. If the problem is with writing or reading a specific entry, we may be already doing all that is possible. I'm not sure how to differentiate the two cases.

(In reply to hawran from comment #8)
> I've just tried to download a couple of different files (at least regarding
> file extensions):
> txt
> m3u
> ...

Did you download these all from the same site, or from multiple sites?

Comment 13

[hawran]

(In reply to :Paolo Amadini [Away] from comment #12)
...
> 
> Did you download these all from the same site, or from multiple sites?

From ONE site.

Comment 14

[:Paolo Amadini]

Well, I'm not sure if we can detect database corruption either. Maybe these problems need to be fixed manually.