Bug: Download folder path selector is disabled in the useDownloadDir radio group, even though this path will always be used unless the action is saveToDisk
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2022-04-03 11:18:56+00:00
Resolved: 2024-03-29 15:01:40+00:00

Okay so there's a problem with the presentation in about:preferences "Downloads" section. If you choose "Always ask you where to save files" then the downloads directory path in the "Save files to" radio button will be disabled. Since it's disabled, it's "grayed out," which gives the impression that the downloads directory path will never be used. Of course, as it's disabled, it also can't be changed.

But it's not true that the downloads directory path will never be used. It remains configured. So, whatever it was set to before you chose `browser.download.useDownloadDir = false`, will end up being the download location if you don't explicitly choose saveToDisk.

So that applies to the actions alwaysAsk, useHelperApp, handleInternally, or useSystemDefault. This can happen if, in the "Applications" section of about:preferences, you configure your handlers to anything but "Save File."

So let's say for the sake of argument that you choose "Always ask" for one of the mime types. Then you download a file of that type. Now the unknown content type dialog appears. The file is already saving in ~/Downloads. If you choose "Save File" it will prompt a "Save as" dialog which will let you choose a different location. But if you choose "Open with Nightly" it will not prompt a "Save as" dialog. So, it winds up saving in ~/Downloads.

In other words, the download directory path selector is just as important when `browser.download.useDownloadDir = false` as when the pref is true. Users need to be able to change that path, irrespective of whether they want the "Save as" dialog or not, because there are other actions besides "Save File." I've seen other people complain about this in comments but don't think anyone has posted an actual report.

The simplest response is to just not disable the path selector input & button. But I don't think that's sufficient. By placing the path selector inside the saveTo radio's hbox, we're associating the path with that option. So even if it's not disabled while the alwaysAsk radio is selected, we're giving the impression that the path is irrelevant to the alwaysAsk radio. I don't know what bearing (if any) this has on the saveToCloud option, by the way.

The whole section could look like this, instead:
```
(•) Save files to [ ~/Downloads ] [ Browse... ]
( ) Save files to Google Drive
[x] Always ask you where to save files
```

Instead of alwaysAsk being another radio button, make it a checkbox. It might have some function for cloud storage anyway? But if not, the checkbox can just be automatically disabled when saveToCloud is selected.

So technically speaking, we have two radio buttons and 1 checkbox. But the saveToCloud radio will be hidden when the platform doesn't support cloud storage. That leaves only 1 visible radio button. So, in addition, saveTo's radio-check will be hidden by CSS as long as the platform doesn't support cloud storage. So that will look like:
```
Save files to [ ~/Downloads ] [ Browse... ]
[x] Always ask you where to save files
```

I'll post some mockup screenshots to make this a bit clearer.