The mobile UI, at least as far as I know, doesn't allow you to configure a DNS-over-HTTPS server, which can be useful as an additional layer for ad filtering no matter on which network you are....
The mobile UI, at least as far as I know, doesn't allow you to configure a DNS-over-HTTPS server, which can be useful as an additional layer for ad filtering no matter on which network you are.
You can do so by modifying the following preferences
Preference
Value
network.trr.mode
2
network.trr.uri
https://dns.adguard-dns.com/dns-query
network.trr.mode
0 - Off (default). use standard native resolving only (don't use TRR at all)
1 - Reserved (used to be Race mode)
2 - First. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.
3 - Only. Only use TRR, never use the native resolver.
Up to FF >= 73, this mode also requires the bootstrapAddress pref to be set.
Starting with Firefox 74, setting the bootstrap address is no longer mandatory - the browser will simply bootstrap itself using regular DNS, unless the DoH server domain can't be resolved.
The native resolver will still be used for portal detection and telemetry (Bug 1593873)
4 - Reserved (used to be Shadow mode)
5 - Off by choice. This is the same as 0 but marks it as done by choice and not done by default.
I used to work on Firefox for Android, particularly on GeckoView, which is the framework for embedding Gecko into apps. I was there when we transitioned the app from the old Fennec architecture...
I used to work on Firefox for Android, particularly on GeckoView, which is the framework for embedding Gecko into apps. I was there when we transitioned the app from the old Fennec architecture over to the new Fenix+GeckoView architecture.
At the time, I supported the hiding of about:config in release builds, and I still do today. The reason is because GeckoView and Android are both significantly different from their desktop counterparts.
A lot of users assume that they should be able to set various about:config knobs the exact same way that they can on desktop, and it just isn't true. In fact, on Android, changing the wrong setting to the wrong value might completely break the installation: in the worst case, it could completely disconnect the rendering engine from the rest of the app. Unless your device is rooted, the only way to fix it is to reinstall the browser (a destructive operation).
A lot of people now say, "I'm willing to take the risk." Well, if you're going to use untested and unsupported settings, then use the beta channel.
"But I want the stability of the release channel." Guess what: you're already significantly breaking stability by tweaking about:config! I would suggest that changing config settings affects stability far more than choosing the beta channel anyway.
As a final digression, a lot of people make changes to about:config settings without even understanding what those settings do. I can't tell you how many times I've seen outdated guides telling users about settings that don't even exist anymore.
Bottom line: if those non-default settings were tested and reliable, they'd either be made default or be made available via the normal preferences GUI. Nobody's intentionally concealing things just to mess with you.
Are you looking for additional browser suggestions? My daily driver is Iceraven. Haven't needed to use anything else in quite a while, and it supports about:config.
Are you looking for additional browser suggestions?
My daily driver is Iceraven. Haven't needed to use anything else in quite a while, and it supports about:config.
The mobile UI, at least as far as I know, doesn't allow you to configure a DNS-over-HTTPS server, which can be useful as an additional layer for ad filtering no matter on which network you are.
You can do so by modifying the following preferences
network.trr.mode2network.trr.urihttps://dns.adguard-dns.com/dns-querynetwork.trr.mode
I used to work on Firefox for Android, particularly on GeckoView, which is the framework for embedding Gecko into apps. I was there when we transitioned the app from the old Fennec architecture over to the new Fenix+GeckoView architecture.
At the time, I supported the hiding of
about:configin release builds, and I still do today. The reason is because GeckoView and Android are both significantly different from their desktop counterparts.A lot of users assume that they should be able to set various
about:configknobs the exact same way that they can on desktop, and it just isn't true. In fact, on Android, changing the wrong setting to the wrong value might completely break the installation: in the worst case, it could completely disconnect the rendering engine from the rest of the app. Unless your device is rooted, the only way to fix it is to reinstall the browser (a destructive operation).A lot of people now say, "I'm willing to take the risk." Well, if you're going to use untested and unsupported settings, then use the beta channel.
"But I want the stability of the release channel." Guess what: you're already significantly breaking stability by tweaking
about:config! I would suggest that changing config settings affects stability far more than choosing the beta channel anyway.As a final digression, a lot of people make changes to
about:configsettings without even understanding what those settings do. I can't tell you how many times I've seen outdated guides telling users about settings that don't even exist anymore.Bottom line: if those non-default settings were tested and reliable, they'd either be made default or be made available via the normal preferences GUI. Nobody's intentionally concealing things just to mess with you.
Are you looking for additional browser suggestions?
My daily driver is Iceraven. Haven't needed to use anything else in quite a while, and it supports about:config.
Ah, ok. I don't, but I'm interested to see what others have to say.