2052678 - custom DoH URL configuration reverts to current provider rather than last used custom provider

Status: RESOLVED DUPLICATE of bug 2048770

(Core :: Networking: DNS, defect, P2)

Description

[Chris Holly]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:152.0) Gecko/20100101 Firefox/152.0

Steps to reproduce:

Open up the settings and look in 'Privacy and Security', then going into DNS over HTTPS. The advanced settings provider is 'Cloudflare' and when changing it to a different provider, then exiting and returning to the same menu.

Actual results:

Despite changing the provider, it always is Cloudflare again. Checking on DNS resolution, it is using the correct provider but it doesn't show up in the visual menu as correct.

Expected results:

It should remain the provider that I originally changed to, not Cloudflare.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Vladimir]

I have same problem. Also see this reddit thread:
https://www.reddit.com/r/firefox/comments/1unb3ne/firefox_quietly_replaces_custom_dns_with/

Problem:
Custom DoH provider is reset to Cloudflare after browser restart (or after toggling Default/Custom)

1. Go to Settings > Privacy & Security > DNS over HTTPS.
2. Set to "Custom" and enter a provider (e.g. Google: "https://dns.google/dns-query").
3. Restart Firefox.

Actual results:
After restart, Firefox starts using Cloudflare instead of the custom Google provider (even if custom field set to Google DNS). In the UI it may still show "Custom", but the actual resolver is Cloudflare. The problem returns every time after restart.

Switching to "Default" and then back to "Custom" (re-entering my custom DNS) temporarily fixes it until the next restart.

Comment 3

[Sunil Mayya]

This looks like the same settings-redesign regression as bug 2043714 (DoH custom select UI forgets that it is in custom mode on reload), where the provider select falls back to the first entry (Cloudflare) on reload because get() runs before getControlConfig(). That fix landed for 153, and the reports here are on 152, so 152 would not have it yet, which matches the behavior described.

bvandersloot, could you confirm whether bug 2043714 fully covers this, including the actual-resolver revert reported in comment 2 (not just the menu display)? If so we can duplicate this to 2043714.

Comment 4

[Manuel Bucher [:manuel]]

I have trouble reproducing due not having any DoH providers pre-configured in preferences page on mozregression builds (openend bug 2054044).

Comment 5

[Benjamin VanderSloot [:bvandersloot]]

Attachment: Bug 2052678 - Use the last custom DoH provider UI in the DoH custom textbox when switching back to Custom - r=manuel!

Comment 6

[Benjamin VanderSloot [:bvandersloot]]

Whoops- didn't see the comment Sunil:

This is actually a different regression than bug 2043714. Bug 2043714 was centered on the state being wrong on reload. This one is about the text in the custom provider box reflecting the current resolver URL, not the custom URL as it was in the old UI. This was originally a design choice in the settings redesign, but with this bug and the use case explained a bit more to me, I think that we should fix this bug.

Let me rename it to be a little bit more clear.

Comment 7

[Phabricator Automation]

Comment on attachment 9606660 [details]
Bug 2052678 - Use the last custom DoH provider UI in the DoH custom textbox when switching back to Custom - r=manuel!

Revision D311542 was moved to bug 2048770. Setting attachment 9606660 [details] to obsolete.

Comment 8

[Manuel Bucher [:manuel]]

Thanks for the report. Fixed in slightly oder bug bug 2048770 (where the attachment was moved to), which this is a duplicate of. This bug discussion is a bit confusing, because from comment 2 to comment 4 a different defect is discussed. That other defect is fixed in bug 2043714 (riding the train with Fx153).