1481595 - Feature to remember the download directory per site doesn't work anymore

Status: RESOLVED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

[Pierre]

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

Steps to reproduce:

Preference "browser.download.lastDir.savePerSite" doesn't seem to exist anymore


Actual results:

The download window opens on the last user dir or the default one... it's less useful

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
20180704003137

Please provide actual steps to reproduce the issue. The following works for me:

1. https://www.mozilla.org
2. Right-click an image, choose "Save Image As…" then save the file.
3. https://en.wikipedia.org/wiki/Main_Page
4. Right-click an image, choose "Save Image As…" then save the file in a different location than before.

Choosing Save Image As… again in either tab then suggests saving the file in the same respective location as before.

(In reply to Pierre from comment #0)
> Preference "browser.download.lastDir.savePerSite" doesn't seem to exist
> anymore

It has never existed by default. Users who want to disable the feature can create it as a new boolean, then set it to false. Bug 702748, comment 12.

Comment 2

[Pierre]

I tested on a Firefox ESR version 52.9.0 (OS debian 9.5) and the feature is working.

I will make some more tests on different versions.

Comment 3

[Pierre]

On my Firefox 61.0.1 on Ubuntu it's not working

Comment 4

[Gingerbread Man]

(In reply to Pierre from comment #2)
> I tested on a Firefox ESR version 52.9.0 (OS debian 9.5) and the feature is
> working.
> 
> I will make some more tests on different versions.

(In reply to Pierre from comment #3)
> On my Firefox 61.0.1 on Ubuntu it's not working

Presumably you used the STR at comment 1, so I'll remove the steps-wanted keyword. If you can reproduce the issue in 61.0.1 in a brand new profile, then it would be helpful if you could find the exact regression range. If the issue disappears in a new profile, then one of your settings or add-ons is most likely at fault.
https://support.mozilla.com/kb/profile-manager-create-and-remove-firefox-profiles
https://mozilla.github.io/mozregression/quickstart.html

Comment 5

[Jan Henning [:JanH]]

I can reproduce this, but curiously enough the regression window I get is approximatively a year later (although since then it's been broken for good):
Somewhere between 2019-07-16 and 2019-07-17.
Unfortunately nothing immediately identifiable stands out in that range. Bug 1554947 possibly seems a little suspicious, though, but needs some further verification.

Comment 6

[Jan Henning [:JanH]]

… and I've actually guessed correctly.

Comment 7

[:Gijs (he/him)]

(In reply to Jan Henning [:JanH] from comment #5)

I can reproduce this, but curiously enough the regression window I get is approximatively a year later (although since then it's been broken for good):
Somewhere between 2019-07-16 and 2019-07-17.
Unfortunately nothing immediately identifiable stands out in that range. Bug 1554947 possibly seems a little suspicious, though, but needs some further verification.

Can you provide detailed steps on how you're testing, starting with a clean profile? As it is, I'm kind of confused why the regression window post-dates the filing of the bug. There's quite a few different paths that lead to saving a file, and I wonder how many are missing a referrer... (x-ref bug 1723712) and which ones we're testing with here.

Comment 8

[Jan Henning [:JanH]]

You have a point - my own STR actually involve opening the images in a new tab and then saving them, as opposed to directly saving them from a page as described in comment #1. The former was and still is broken by bug 1554947, whereas the latter seems to have been partially broken by that change, but then fixed again at some point (following the steps in comment #1 for a build immediately after bug 1554947, saving images on mozilla.org resets the download directory for images on Wikipedia, but not vice versa – but at some point that seems to have been fixed, because in a current Nightly this works fine).

I guess I'll open a separate issue for this then, sorry for the slight confusion :-)