DefaultDownloadDirectory in policies.json results in locked "save files to" UI for user
Categories
(Firefox :: Enterprise Policies, defect)
Tracking
()
People
(Reporter: pascal.reintjens, Assigned: mkaply)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-esr115+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Steps to reproduce:
- Created a policies.json file where
DefaultDownloadDirectory
is set to${home}\\Downloads
:
{
"policies": {
"DefaultDownloadDirectory": "${home}\\Downloads"
}
}
- Subsequently, placed this file within the installation directory: C:\Program Files\Mozilla Firefox\distribution\policies.json
- 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•2 months ago
|
||
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•2 months ago
|
||
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.
Assignee | ||
Comment 3•2 months ago
|
||
Is clicking on the browser button not working?
Reporter | ||
Comment 4•2 months ago
|
||
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.
Assignee | ||
Comment 6•2 months ago
|
||
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.
Assignee | ||
Comment 7•2 months ago
|
||
Updated•2 months ago
|
Comment 8•2 months ago
|
||
Set release status flags based on info from the regressing bug 1762775
Updated•2 months ago
|
Pushed by mozilla@kaply.com: https://hg.mozilla.org/integration/autoland/rev/d91454921bde Don't set/lock folderList when download dir is set. r=kcochrane
Comment 10•2 months ago
|
||
bugherder |
Comment 11•2 months ago
|
||
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
towontfix
.
For more information, please visit BugBot documentation.
Comment 12•2 months ago
|
||
ESR also :)
Assignee | ||
Comment 13•2 months ago
|
||
I usually let stuff like this ride the train and do ESR then, but it's so minor, probably worth doing.
Assignee | ||
Comment 14•2 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D206116
Updated•2 months ago
|
Assignee | ||
Comment 15•2 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D206116
Updated•2 months ago
|
Comment 16•2 months ago
|
||
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•2 months ago
|
||
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
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 18•2 months ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/fd81550c5cd3
Comment 19•2 months ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-esr115/rev/f299bfa481d7
Updated•2 months ago
|
Description
•