[Affected Platforms]:

• Windows 10x64
• Windows 7x64
• macOS 10.15
• Ubuntu 18.04x64

[Affected Versions]:

• Firefox Beta 72.0b5

[Prerequisites]:

• Add the policies.json in the firefox/distribution folder with the following content:
  {
  "policies": {
  "DNSOverHTTPS": {
  "Enabled": true,
  "ProviderURL": "https://mozilla.cloudflare-dns.com/dns-query",
  "Locked": true
  }
  }
  }

Or

{
"policies": {
"DisablePocket": true
}
}
Or set from ADMX those policies for Windows.

[Steps to reproduce]:

1. Open the browser.
2. Go to about:config and add doh-rollout.enabled to true.
3. Go to about:telemetry#events-tab.
4. Bring back in focus the about:config page.
5. Wait ~1min.

[Expected result]:

• The "network.trr.mode" pref doesn't change its value.
• The DoH doorhanger is not displayed.

[Actual result]:
Here are a few scenarios depending on which policy was set:

1. If Pocket policy is set (via JSON or ADMX)
   a. The network.trr.mode pref is 0 and policy_without_doh telemetry is received.
   b. After ~1min the network.trr.mode is flipped to 2, doorhanger is displayed and enable_doh telemetry is received.
2. DNS policy is set to disable (via JSON or ADMX)
   a. The network.trr.mode pref is 5 and disable_doh telemetry is received.
   b. After ~1min the network.trr.mode is flipped to 0 and another disable_doh telemetry is received (NOTE if DNS policy is set by JSON and the network.trr.mode pref is locked, the value for network.trr.mode remains 5).
3. DNS policy is set to enable(via JSON or ADMX)
   a. The network.trr.mode pref is 2 and enable_doh telemetry is received.
   b. After ~1min the network.trr.mode is not flipped but another enable_doh telemetry is received and the DOH doorhanger is displayed (NOTE if DNS policy is set by JSON and the network.trr.mode pref is locked, the value for network.trr.mode remains 2).

[Notes]:

• The issue is reproducible with the 1.3.0 in-tree add-on.
• I have attached a screen recording of the issue

This issue also occurred in v1.2 — The patch that solved it can be found here. I recommend adding the same check here.

Seems like that setting is set only once, at startup. I think we can just return early in init() if we hit that, and just not add our network/captive portal listeners.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/105afaccc63b
The 1.3.0 in-tree add-on doesn't respect user's set policies r=nhnt11

Maxx: In general to request landing of a patch, please use the Edit Revision link in Phabricator and add the tag Check-In Needed.

Comment on attachment 9115782 [details]
Bug 1603478 - The 1.3.0 in-tree add-on doesn't respect user's set policies r?nhnt11

Beta/Release Uplift Approval Request

• User impact if declined: This bug causes DoH heuristics to not respect enterprise policies.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The fix is to add a simple conditional check that was omitted. The add-on is pref'd off by default. Automated tests are coming soon™️.
• String changes made/needed:

https://hg.mozilla.org/mozilla-central/rev/105afaccc63b

(In reply to Sebastian Hengst [:aryx] [limited availability until start of 2020] (needinfo on intermittent or backout) from comment #6)

Maxx: In general to request landing of a patch, please use the Edit Revision link in Phabricator and add the tag Check-In Needed.

Will do! Thanks, aryx!

Comment on attachment 9115782 [details]
Bug 1603478 - The 1.3.0 in-tree add-on doesn't respect user's set policies r?nhnt11

DoH add-on fix, approved for 72.0b9

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

Hello,

I can confirm that this issue is fixed on Fx 72.0b10 on Windows 10 x64, Ubuntu 18.04 and mac OS 10.15.

Hello,

Sorry for the long delay. This issues is also verified on Nightly 73.0a1 (BuildID: 20191224212327).