Closed Bug 1762775 Opened 2 years ago Closed 2 years ago

Download folder path selector is disabled in the useDownloadDir radio group, even though this path will always be used unless the action is saveToDisk

Categories

(Firefox :: Settings UI, defect, P2)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
101 Branch
Tracking Status
firefox100 --- wontfix
firefox101 --- fixed

People

(Reporter: aminomancer, Assigned: aminomancer)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fidefe-2022-downloads-followup])

Attachments

(4 files, 1 obsolete file)

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.

How it should appear when cloud storage is available but not in use

How it should appear when cloud storage is in use

How it should actually appear when cloud storage is unavailable.

Of course, to achieve this, instead of just hiding the radio-check element, the entire <radio> could just be hidden, and a separate <description> or something could be added that says "Save files to". Maybe that's better since it would avoid unnecessarily capturing events.

Attachment #9270590 - Attachment is obsolete: true
Attachment #9270591 - Attachment description: How it should appear when cloud storage is enabled but not in use → How it should appear when cloud storage is available but not in use
See Also: → 1759779

We're trying to remove the cloud storage support - https://phabricator.services.mozilla.com/D137248 - bug 1751093. We shouldn't worry too much about that case here.

Severity: -- → S3
Depends on: 1751093
OS: Unspecified → All
Whiteboard: [fidefe-2022-downloads-followup]
Priority: -- → P2

(In reply to :Gijs (he/him) from comment #5)

We're trying to remove the cloud storage support - https://phabricator.services.mozilla.com/D137248 - bug 1751093. We shouldn't worry too much about that case here.

Thanks for letting me know. Idk how to avoid accounting for it though. If we just hide the radio check for everyone then I think people who have cloud storage enabled won't be able to turn it off unless they know what prefs they're looking to change in about:config. So maybe my whole idea about hiding the radio check is just the wrong approach

(In reply to Shane Hughes [:aminomancer] from comment #6)

(In reply to :Gijs (he/him) from comment #5)

We're trying to remove the cloud storage support - https://phabricator.services.mozilla.com/D137248 - bug 1751093. We shouldn't worry too much about that case here.

Thanks for letting me know. Idk how to avoid accounting for it though. If we just hide the radio check for everyone then I think people who have cloud storage enabled won't be able to turn it off unless they know what prefs they're looking to change in about:config. So maybe my whole idea about hiding the radio check is just the wrong approach

No, I think the state in attachment 9270593 [details] looks good to me as a goal here. I'll ping Punam in bug 1751093.

The default download folder prefs are now counterintuitively used
whether browser.download.useDownloadDir is enabled or not, since we no
longer save downloads to the "temp" folder. But the display for these
prefs in about:preferences makes it seem as though the configured path
will not be used if the "Always ask..." option is selected. This patch
removes the radiogroup and replaces it with a checkbox, so that the
download folder path can be changed irrespective of useDownloadDir's
value (unless browser.download.dir is disabled by policy).

Assignee: nobody → shmediaproductions
Status: NEW → ASSIGNED
Blocks: 1744297
Attachment #9272044 - Attachment description: Bug 1762775 - Change download folder display in prefs UI. r=jaws,Gijs → Bug 1762775 - Change download folder display in prefs UI. r=dao,flod
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/cdcb4f5551fb
Change download folder display in prefs UI. r=Gijs,fluent-reviewers,preferences-reviewers,desktop-theme-reviewers,dao,flod
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Regressions: 1767367
See Also: → 1758791
You need to log in before you can comment on or make changes to this bug.