Access Connector is broken when live policy is applied
Categories
(Enterprise Products :: Firefox, defect, P1)
Tracking
(Not tracked)
People
(Reporter: jporter, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
Attachments
(3 files)
When toggling the AccessConnector policy in the console with an active browser open, the AccessConnector button is shown and hidden, but the underlying functionality is broken. Navigating to webpages under the policy do not work or show an active state. This applies to enterprise-release as well.
Steps to Reproduce
- Have
AccessConnectorpolicy set in console - Launch browser and navigate to a webpage protected by policy
- Observe an
activetoolbar button and panel - Remove the policy in console
- Observe the Access Connector button disappear from toolbar
- Re-add the policy in console
- Observe the Access Connector button appear in toolbar
- Navigate to a protected page
- Observe an
inactivetoolbar button and panel
Updated•4 months ago
|
Updated•4 months ago
|
Comment 1•4 months ago
|
||
First thing I see that that we keep the matching parameters when we perform onRemove: https://searchfox.org/enterprise-main/rev/11acd910851157e4c161e4eb32623217ab1d0f0a/browser/components/enterprisepolicies/Policies.sys.mjs#191-193 we probably do not want that
Comment 2•4 months ago
|
||
All of the prefs are properly restored but indeed feature is not enabled.
Comment 3•4 months ago
|
||
Another set of STR is just start without the policy defined on the console, and define the policy after browser is running
Comment 4•4 months ago
|
||
(In reply to :gerard-majax from comment #3)
Another set of STR is just start without the policy defined on the console, and define the policy after browser is running
I have a patch that works for the STRs of comment 0, but not for those: I get into state ready, entitlement is fetched but feature is not working
Comment 5•4 months ago
|
||
(In reply to :gerard-majax from comment #3)
Another set of STR is just start without the policy defined on the console, and define the policy after browser is running
Comment 6•4 months ago
|
||
(In reply to :gerard-majax from comment #5)
(In reply to :gerard-majax from comment #3)
Another set of STR is just start without the policy defined on the console, and define the policy after browser is running
OK there is this, and there is also the fact that we get auto start pref enabled a bit before the server list is set as a pref by the code. Changing the factory properly make sure we use preferences based list, but we may hit https://searchfox.org/enterprise-main/rev/11acd910851157e4c161e4eb32623217ab1d0f0a/toolkit/components/ipprotection/IPPAutoStart.sys.mjs#87-89 when it is not yet ready even though the enable pref is. Fortunately it emits an event, so we can just listen to it.
With those changes, I have something that seems to work in all cases
Comment 7•4 months ago
|
||
Comment 8•4 months ago
|
||
Comment 9•4 months ago
|
||
Comment 10•4 months ago
|
||
Authored by Alexandre Lissy
https://github.com/mozilla/enterprise-firefox/commit/18fd1e4313bc6b353437dbe2a5eadcc27da06eb3
[enterprise-main] Bug 2034591 - Enterprise: make sure to properly react to policy changes for Access Connectors
Authored by https://github.com/jporter-dev
https://github.com/mozilla/enterprise-firefox/commit/a8955675c367fb0459db7fff72ff1b04f7a00506
[enterprise-main] Bug 2034591 - Enterprise: avoid IPProtection serverlist error on clean profile when pref is unset
Authored by https://github.com/lissyx
https://github.com/mozilla/enterprise-firefox/commit/f9048334eccd943cb2865aae56c2f2bffb5c285f
[enterprise-main] Merge pull request #788 from lissyx/enterprise-bug2034591_fix_access_connectors_live_changes
Comment 11•4 months ago
|
||
Please note the release PR was NOT merged on purpose, because it may not be needed from a customer perspective. But it is there if we need it.
Comment 12•4 months ago
|
||
I was curious so I tested it on 152.0a1 20260424201906 on macOS Tahoe and Win 11 and can confirm that after a page refresh the policy removal and adding it again applies these changes live (one domain requires a page refresh):
- The AccesConnector is no longer displayed after being removed
- the AccessConnector icon is restored when policy is re-applied
- active and inactive states are showing as expected on approved domains/ inactive domains navigation
Comment 13•4 months ago
|
||
Miruna, can I ask you to verify also on my PR on release? As mentionned in comment 11 we do not land it for now as there is no pressing requirement, but I'd like to triple check we are fine (we already checked with josh, but a QA validation cannot do any harm)
It should be from tasks:
- https://firefox-ci-tc.services.mozilla.com/tasks/cB_Q7nuSSee5RqtQWtNBJg
- https://firefox-ci-tc.services.mozilla.com/tasks/e2F-acIKRE26DzB3NRwxLg
- https://firefox-ci-tc.services.mozilla.com/tasks/ZdIbemsSS3Ok5G9lqzJ1Zw
Artifacts expires in 24 days :)
Comment 14•4 months ago
•
|
||
(In reply to :gerard-majax from comment #13)
Miruna, can I ask you to verify also on my PR on release? As mentionned in comment 11 we do not land it for now as there is no pressing requirement, but I'd like to triple check we are fine (we already checked with josh, but a QA validation cannot do any harm)
It should be from tasks:
- https://firefox-ci-tc.services.mozilla.com/tasks/cB_Q7nuSSee5RqtQWtNBJg
- https://firefox-ci-tc.services.mozilla.com/tasks/e2F-acIKRE26DzB3NRwxLg
- https://firefox-ci-tc.services.mozilla.com/tasks/ZdIbemsSS3Ok5G9lqzJ1Zw
Artifacts expires in 24 days :)
Tested on Win 11, macOS Tahoe 26.3 and Ubuntu 24.04 using 150.1.0 20260424161857. The policy can be applied, removed and applied again live and is active on the specified domain (used this method because at least here, it is still broken on first run).
Updated•3 months ago
|
Comment 15•3 months ago
|
||
Marking this as verified fixed on Win 11, macOS Tahoe 26.3 and Ubuntu 24.04 using 151.0 20260516231850. The policy can be applied, removed and apllied again (using a different math pattern) and the icon is available in the toolbar while the axpected domains are active.
Tested using:
1.
{
"Host": "proxy.enterfox.eu",
"MatchPatterns": [
"https://*.mozilla.org",
"https://mozilla.org",
"http://enterprise-console-static.default.svc.cluster.local"
],
"Port": 443
}
{
"Host": "proxy.enterfox.eu",
"MatchPatterns": [
"<all_urls>"
],
"Port": 443
}
{
"Host": "proxy.enterfox.eu",
"MatchPatterns": [
"https://.mozilla.org/"
],
"Port": 443
}
Updated•3 months ago
|
Description
•