1885362 - DefaultDownloadDirectory in policies.json results in locked "save files to" UI for user

Status: RESOLVED FIXED

(Firefox :: Enterprise Policies, defect)

Description

[Pascal Reintjens]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

1. Created a policies.json file where DefaultDownloadDirectory is set to ${home}\\Downloads:

{
	"policies": {
		"DefaultDownloadDirectory": "${home}\\Downloads"
	}	
}

2. Subsequently, placed this file within the installation directory: C:\Program Files\Mozilla Firefox\distribution\policies.json
3. restarted the browser and went to Settings > General > Downloads

Actual results:

The "save files to" option is now set to "Downloads" but it is now locked and the user is unable to change the Path within the UI.

-> It nearly behaves the same as DownloadDirectory just with the checkbox "Always ask where to save files" not locked.

Expected results:

Since it is a default policy, the "save files to" option should not be locked - the user should still be provided by default with the directory specified in this policy but should be able to change this directory in the settings UI.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Enterprise Policies' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Monica Chiorean]

I was able to reproduce what Pascal Reintjens, mentioned on description on Win11x64 using FF build 124.0, but we still need engineering input on this.
Mike Kaply, can you please express the expected behavior on this issue? Thank you.

Comment 3

[Mike Kaply [:mkaply]]

Is clicking on the browser button not working?

Comment 4

[Pascal Reintjens]

I hope it's fine that I respond.
The whole row "Save files to" including the "Browse..." Button gets greyed out, so the user can't click the button.

Comment 5

[Mike Kaply [:mkaply]]

OK, I'll take a look.

Comment 6

[Mike Kaply [:mkaply]]

So it looks this was regressed in 2022 and wasn't caught.

The behavior in prefs was changed to lock everything when browser.download.folderList was locked.

Comment 7

[Mike Kaply [:mkaply]]

Attachment: Bug 1885362 - Don't set/lock folderList when download dir is set. r?kcochrane

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1762775

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d91454921bde
Don't set/lock folderList when download dir is set. r=kcochrane

Comment 10

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/d91454921bde

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:mkaply, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox125 to wontfix.

For more information, please visit BugBot documentation.

Comment 12

[(PTO May 7-12) Ryan VanderMeulen [:RyanVM]]

ESR also :)

Comment 13

[Mike Kaply [:mkaply]]

I usually let stuff like this ride the train and do ESR then, but it's so minor, probably worth doing.

Comment 14

[Mike Kaply [:mkaply]]

Attachment: Bug 1885362 - Don't set/lock folderList when download dir is set. r?kcochrane

Original Revision: https://phabricator.services.mozilla.com/D206116

Comment 15

[Mike Kaply [:mkaply]]

Attachment: Bug 1885362 - Don't set/lock folderList when download dir is set. r?kcochrane

Original Revision: https://phabricator.services.mozilla.com/D206116

Comment 16

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: UI locked when it shoudn't be
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: N/a
• Risk associated with taking this patch: Low/None
• Explanation of risk level: Removes unneeded code in policy
• String changes made/needed: None
• Is Android affected?: no

Comment 17

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: Pref is locked unnecesarily
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: Low/none
• Explanation of risk level: Removal of unneded line in policy
• String changes made/needed: None
• Is Android affected?: no

Comment 18

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/fd81550c5cd3

Comment 19

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/f299bfa481d7