Review (live ?) policies and make sure their application properly handle all cases
Categories
(Enterprise Products :: Firefox, task)
Tracking
(Not tracked)
People
(Reporter: gerard-majax, Assigned: gerard-majax)
References
(Depends on 1 open bug)
Details
Attachments
(3 files)
image.png
In bug 2026214, the issue was mostly because the server was sending BlockAboutConfig with a value false that was not handled at all. We should review policies and make sure their application is correct, for any policy that can be pushed from the server. Here for example:
diff --git a/browser/components/enterprisepolicies/Policies.sys.mjs b/browser/components/enterprisepolicies/Policies.sys.mjs
index 4d48115d2d060..dd37a4da7967a 100644
--- a/browser/components/enterprisepolicies/Policies.sys.mjs
+++ b/browser/components/enterprisepolicies/Policies.sys.mjs
@@ -530,6 +530,9 @@ export var Policies = {
if (param) {
blockAboutPage(manager, "about:config");
setAndLockPref("devtools.chrome.enabled", false);
+ } else {
+ unblockAboutPage(manager, "about:config");
+ setAndLockPref("devtools.chrome.enabled", true);
}
},
onRemove(manager, oldParams) {
While previously this may not have been relevant, the showcased example in bug 2026214 is simply:
- boot with no policy
- admin sets policy to true (blocking)
- then admin sets policy to false
|
||
Comment 1•3 months ago
|
||
|
Assignee | |
Comment 2•3 months ago
|
||
There are some cases where the console UI allows to set true or false, but I'm not sure if it really is meaningful, cf the attached example of DIsablePrivateBrowsing
|
|
||
Comment 3•3 months ago
|
||
Authored by Alexandre Lissy
https://github.com/mozilla/enterprise-firefox/commit/24447cb4a3eef177bccc79bd64cfe435a020153a
[enterprise-main] Bug 2027104 - Enterprise: Fix Policies application
Authored by https://github.com/lissyx
https://github.com/mozilla/enterprise-firefox/commit/3cc4d877a125ffb9b6e8e2b4670fd0154c5b449a
[enterprise-main] Merge pull request #626 from lissyx/enterprise-bug2027104_fix_more_live_policies
|
|
||
Comment 4•3 months ago
|
||
|
|
||
Comment 5•3 months ago
|
||
Authored by https://github.com/jonathanmendez
https://github.com/mozilla/enterprise-firefox/commit/dc03c1a25837451d35f562f4b95c6308692924e1
[enterprise-main] Bug 2027104 - Fix more live policy application issues
Authored by https://github.com/jonathanmendez
https://github.com/mozilla/enterprise-firefox/commit/e777f24fecf3e650448de729180ed2f46bb3391e
[enterprise-main] Merge pull request #685 from jonathanmendez/policies-follow-up
|
||
Comment 6•2 months ago
|
||
So far in testing the 150.0 (20260419183446) smoke build on macOS Tahoe 26.3 I've checked:
- unblock live policy works after refresh for about:config, about:profiles and about:support when changing True to FF default or Inherit FF default
- DisablePrivateBrowsing however need a restart in order to be applied as True, False or FF default (policy is updated in about:policies but functionality is not updated live)
- From the list of (unconfirmed) live policies, which others should we test?
|
|
Assignee | |
Comment 7•2 months ago
|
||
(In reply to Miruna Curtean from comment #6)
So far in testing the 150.0 (20260419183446) smoke build on macOS Tahoe 26.3 I've checked:
- unblock live policy works after refresh for about:config, about:profiles and about:support when changing True to FF default or Inherit FF default
- DisablePrivateBrowsing however need a restart in order to be applied as True, False or FF default (policy is updated in about:policies but functionality is not updated live)
Is this true on enterprise-main builds as well?
- From the list of (unconfirmed) live policies, which others should we test?
Ideally, all of those since we advertise they are live
|
|
||
Comment 8•2 months ago
•
|
||
(In reply to :gerard-majax from comment #7)
(In reply to Miruna Curtean from comment #6)
So far in testing the 150.0 (20260419183446) smoke build on macOS Tahoe 26.3 I've checked:
- unblock live policy works after refresh for about:config, about:profiles and about:support when changing True to FF default or Inherit FF default
- DisablePrivateBrowsing however need a restart in order to be applied as True, False or FF default (policy is updated in about:policies but functionality is not updated live)
Is this true on
enterprise-mainbuilds as well?
To note, the functionality that only changes after restart refers to the options (new tab+ new window+ new private window) from the Hamburger menu, but while testing this in-depth I realized we should also check what happens when opening a new tab live and about:privatebrowsing.
These are the results for both enterprise release 150.0 (20260419183446) and Enterprise-main 151.0a1 (Build ID: 20260421055443) - -all changes applied at user level as they are easier to track. I've marked as Bold the only difference I see between these 2 builds, that occurs when switching the policy value from True to False.
FF default
about:policies - DisablePrivateBrowsing not listed - as expected
New tab - opens new tab
about:privatebrowsing - unblocked
Hamburger menu: new tab + new window+ new private window
**FF default> True **
Live changes:
about:policies - DisablePrivateBrowsing listed as True - after page refresh
New tab - opens new tab
about:privatebrowsing - blocked live (access to this site is restricted)
After restart:
Hambuger menu: new tab + new window+ new private window > new tab +New window
True> False
Live changes:
about:policies - updates after refresh
New tab - opens new tab (live and after restart)
enterprise-main: about:privatebrowsing- opens private browsing tab in the same window
enterprise release: about:privatebrowsing- "You are currently not in a private window" + "Open a private window button" -weird live behavior
After restart:
Hambuger menu: new tab + new window> new tab + new private window (only after restart)
Note: all open tabs are closed and the LDAP account is signed out from console after restart
False >True
Live changes:
about:policies - updates after refresh
New tab - opens about:privatebrowsing live
about:privatebrowsing - blocked live (access to this site is restricted)
After restart:
Hambuger menu: new tab + new private window > new tab + new window ( only after restart)
False>True>Keep Firefox Default
Live changes:
about:policies - updates after refresh
New tab - opens a regular new tab live
about:privatebrowsing- "You are currently not in a private window" + "Open a private window button"
After restart:
Hambuger menu: new tab + new window > new tab + new window+ new private window ( only after restart)
The final questions are:
- are all these changes (hamburger menu tabs+windows included) expected to work live?
- Should we and log a separate issue for the DisablePrivateBrowsing switch from True to False and how this affects the about:privatebrowsing page live on the release build?
- From the list of (unconfirmed) live policies, which others should we test?
Ideally, all of those since we advertise they are live
Eventually it would be a good idea to do so, but since we are not familiar with the rest of the policies it is hard to estimate how much it would take to discover and test a high number of use cases, as in the DisablePrivateBrowsing example.
I'm going to include Brian to help with this decision. Would you like QA to prioritize checking the behavior of all the live policies in the following days or just specific ones for now?
To note that we should also allocate about a full day of testing all possible combinations for 2027783.
|
||
Comment 9•2 months ago
|
||
Thanks for the investigation.
Would you like QA to prioritize checking the behavior of all the live policies in the following days
I think cherry-picking some policies (e.g., BlockAbout*) is sufficient for this case. Let's discuss the strategy for testing all policies that don't require a restart in our next sync.
|
||
Comment 10•2 months ago
|
||
Tested the 150.0 (20260419183446) smoke build on Ubuntu 24.04.4
Live policies tested:
- BlockAboutAddons
- BlockAboutConfig
- BlockAboutProfiles
- BlockAboutSupport
STR: Set to True > False > True > Firefox default> True > Inherit Fx Default
The policies applies live (after a few seconds) and blocks/unblocks pages as expected.
Thank you
|
|
||
Updated•2 months ago
|
|
||
Comment 11•2 months ago
|
||
The Block:AboutAddons, Block:AboutConfig, Block:AboutProfiles and Block:AboutSupport policies are applied in real time and correctly block or unblock the respective pages.
I've verified this using Firefox Enterprise 150.0 (20260419183446) on Windows 10/11.
|
|
||
Updated•2 months ago
|
|
||
Comment 12•2 months ago
|
||
So are we opening separate bugs for the ones that don't work live?
|
|
||
Comment 13•2 months ago
|
||
QA team are looking at other policies that don't require restart (i.e., "live") in a follow-up at the moment.
Description
•