Closed Bug 2034591 Opened 4 months ago Closed 4 months ago

Access Connector is broken when live policy is applied

Categories

(Enterprise Products :: Firefox, defect, P1)

Tracking

(Not tracked)

VERIFIED FIXED

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

  1. Have AccessConnector policy set in console
  2. Launch browser and navigate to a webpage protected by policy
  3. Observe an active toolbar button and panel
  4. Remove the policy in console
  5. Observe the Access Connector button disappear from toolbar
  6. Re-add the policy in console
  7. Observe the Access Connector button appear in toolbar
  8. Navigate to a protected page
  9. Observe an inactive toolbar button and panel
Severity: -- → S1
Priority: -- → P1

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

All of the prefs are properly restored but indeed feature is not enabled.

Another set of STR is just start without the policy defined on the console, and define the policy after browser is running

(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

(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 suspect https://searchfox.org/enterprise-main/rev/11acd910851157e4c161e4eb32623217ab1d0f0a/toolkit/components/ipprotection/IPProtectionServerlist.sys.mjs#460

(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

I suspect https://searchfox.org/enterprise-main/rev/11acd910851157e4c161e4eb32623217ab1d0f0a/toolkit/components/ipprotection/IPProtectionServerlist.sys.mjs#460

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

Blocks: 2034845

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

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED

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.

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

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:

Artifacts expires in 24 days :)

Flags: needinfo?(mcurtean)

(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:

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).

Flags: needinfo?(mcurtean)
Flags: qe-verify+

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
}

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressed by: 2040983
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: