Disconnecting from the internet causes the "network.trr.mode" preference value to temporarily change from "2" to "0" on macOS
Categories
(Shield :: Shield Study, defect)
Tracking
(firefox73 affected, firefox74 affected)
People
(Reporter: ppop, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
|
82 bytes,
text/plain
|
Details |
[Affected Platforms]:
- Mac 10.15.2
- Mac 10.14.6
[Affected Versions]:
- Firefox Nightly 74.0a1, Build ID 20200205215017
- Firefox Beta 73.0, Build ID 20200203203546
[Prerequisites]:
- Have a profile enrolled in preference-rollout experiment that sets the "doh-rollout.enabled" to "true". (recipe 927)
- Have the "security.content.signature.root_hash" pref set to "DB:74:CE:58:E4:F9:D0:9E:E0:42:36:BE:6C:C5:C4:F6:6A:E7:74:7D:C0:21:42:7A:03:BC:2F:57:0C:8B:9B:90".
- Have the "app.normandy.api_url" pref set to "https://stage.normandy.nonprod.cloudops.mozgcp.net/api/v1".
- Have the "app.normandy.dev_mode" set to "true".
- Have the "app.normandy.logging.level" set to "0".
- Have the "services.settings.server" set to "https://settings.stage.mozaws.net/v1".
- Have the "ppop-doh-roll" pref set to "true".
[Steps to reproduce]:
- Open the browser with the profile from prerequisites.
- Navigate to about:config and search for the "network.trr.mode" preference.
- Disable the internet connection and observe the value of the pref.
[Expected result]:
- The "network.trr.mode" pref vaue remains "2".
[Actual result]:
- The "network.trr.mode" pref value changes to "0"
[Notes]:
- Reconnecting to the internet causes the "network.trr.mode" pref value to change back to "2".
- In about:telemetry both "disable_doh" and "enable_doh" events are displayed.
- The issue is not reproducible on Windows and Linux.
- The following Normandy recipes were used: pref-rollout.
- I have attached a screen recording of the issue:
Comment 1•6 years ago
|
||
This is semi-intentional to ensure that we start with DoH disabled when connecting to a new network. I don't think this is a bug, but I'm not sure if we want to suppress the telemetry in this case.
| Reporter | ||
Comment 2•6 years ago
|
||
I understand, however, why are we seeing this behavior only on macOS and not on Windows and Linux? Regarding telemetry, on Windows and Linux after a network change all events are cohesive (multiple enable_doh) while on macOS there are contracticting events (disable_doh and enable-doh).
Comment 3•6 years ago
|
||
I think there are differences in the way the network link service responds to system-level network changes. Dragana/Valentin, can you comment on this?
Comment 4•6 years ago
•
|
||
I don't see this as a blocker. It appears that on MacOS we get a network change event when wifi goes down before the network status changes to "down". So we see "up" and run heuristics. The outcome of this bug is an extra heuristics run so we get some extra telemetry, but nothing "bad" happens.
Comment 5•6 years ago
|
||
As long as the final outcome (enable_doh or disable_doh) is correct for each network change on each platform, I don't think this is a blocker. The extra telemetry is confusing and should be fixed, but as long as DoH is disabled and enabled correctly the addon is doing its job. When there's no connection to the internet, trr.mode is set to 0 because the addon can't reach the canary domain, and it's reset to 2 when it can connect to the internet again. trr.mode does not matter when Firefox has no connectivity.
(In reply to Nihanth Subramanya [:nhnt11] from comment #4)
It appears that on MacOS we get a network change event when wifi goes down before the network status changes to "down".
I filed bug 1613860 for that.
Description
•