Closed Bug 1481595 Opened 6 years ago Closed 3 years ago

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

Categories

(Toolkit :: Downloads API, defect)

70 Branch
Desktop
Unspecified
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: pierre42d, Unassigned)

References

(Regression)

Details

(Keywords: regression)

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
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.
Has STR: --- → no
Component: Untriaged → Downloads API
Flags: needinfo?(pierre42d)
Keywords: steps-wanted
Product: Firefox → Toolkit
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.
Flags: needinfo?(pierre42d)
On my Firefox 61.0.1 on Ubuntu it's not working
(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
Has Regression Range: --- → no
Has STR: no → yes
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE

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.

Status: RESOLVED → REOPENED
Ever confirmed: true
OS: Linux → Unspecified
Hardware: x86_64 → Desktop
Resolution: INACTIVE → ---
Version: 61 Branch → Trunk

… and I've actually guessed correctly.

Regressed by: 1554947
Version: Trunk → 70 Branch
Has Regression Range: no → yes

(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.

Flags: needinfo?(jh+bugzilla)

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 :-)

Status: REOPENED → RESOLVED
Closed: 6 years ago3 years ago
Flags: needinfo?(jh+bugzilla)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.