Eclipse Community

These UDP and TCP exist in "real" Firefox, ie, not a fork but the "real" Firefox.
You don't like me saying this, but IceCat does not have these.
It's all tied to background connections. DNS, TCP, UDP, all of the above.

The-10-Pen wrote: *

06 May 2026, 17:13

IceCat does not have these.

Latest version of Icecat for Windows I've found is v115.24.0 which is based on Firefox ESR with the same version number.
I actually have Firefox v115.35.1 ESR installed and it behaves like Icecat but the base of these versions is quite old now. There have been many changes since Firefox 128 and 140 so I think v150 is closer to v140 than to v115.

And don't forget my troubles occur when using Quad9 with the Max Protection setting of the DNS over HTTPS so in case of failure there should be no fall back at all in any case but an error/warning message.

Agreed. Icecat is at 140.3.1, but only for Linux. The Windows distribution is basically "abandonware".

But my main point kind of remains, this is an "upstream" issue with all of the under-the-hood changes from Official Upstream Real v14x.y and Official Upstream Real v150.z.

Duke wrote: *

06 May 2026, 10:39

There is also a problem with the HTTP Version field.

This is also an "upstream" issue.
"Real" Firefox has this bug, therefore **ALL** forks will have this bug.
If you want a challenge, try to find *any* 'fox fork that doesn't have this issue.
It's not the ekx-forget-his-name fork that was requested to check if it occurs there.
Since it is in "real" 'fox, it's going to be in *ALL* forks of 'fox.

The-10-Pen wrote: *

06 May 2026, 21:50

"Real" Firefox has this bug, therefore **ALL** forks will have this bug.

Nice catch, I shoud have tried it before posting.

I'm really not trying to beat a Dead Horse.
I was really looking forward to Icecat's anti-telemetry strategy (but again, it is now basically "abandonware" for Windows).
They were really the only, and I do mean *ONLY* 'fox fork that TOOK TELEMETRY SERIOUSLY!
Everybody else, and I do mean everybody else just writes it off as "it's not that important, live in a cardboard box if it worries you that much".

Or writes off DNS versus TCP or whatever. Again, not to beat the Dead Horse, but there really should NEVER be any DNS (or TCP or UDP) entries just for OPENING a browser defaulting to an about:blank page. NEVER. Not in a million seconds. A browser should NEVER contact the "internet" until the user opens a bookmark or enters a URL. NEVER. No, it's not "paranoia", it's just COMMON SENSE. And H#LL, if a user is jumping through hoops to disable whatever a "detectportal" is (something that to me should be OFF by **DEFAULT**), then why "minimize" OTHER users allocating EQUAL IMPORTANCE to every other DOZEN upon DOZEN of those d@mn "Mozilla Connections" that have NO VALUE in a Consumer Aware Web Browser?

Not to be misread, of course. NO BROWSER IS PERFECT.
But isn't that WHY we are all here? To STRIVE for one that IS at least CLOSER to perfect?

Anything short of that, in my opinion, kind of falls under the same pretense as this:

First they came for the Communists
And I did not speak out
Because I was not a Communist
Then they came for the Socialists
And I did not speak out
Because I was not a Socialist
Then they came for the trade unionists
And I did not speak out
Because I was not a trade unionist
Then they came for the Jews
And I did not speak out
Because I was not a Jew
Then they came for me
And there was no one left
To speak out for me

~Martin Niemoller, 1946

The-10-Pen wrote: *

07 May 2026, 11:09

Or writes off DNS versus TCP or whatever.

I wish some other R3dfox users to report about this behavior.
The original post is there: https://board.eclipse.cx/viewtopic.php?p=8994#p8994

The-10-Pen wrote: *

07 May 2026, 11:09

whatever a "detectportal" is (something that to me should be OFF by **DEFAULT**)

Not everyone is tech savvy. That's why it's enabled by default because it can be very useful.
https://support.mozilla.org/en-US/kb/captive-portal

Duke wrote: *

05 May 2026, 13:42

Since DNS over HTTPS obviously use HTTPS therefore it should use the TCP protocol.

But in about:networking with R3dfox v150.0.1 I'm seeing UDP being used.
While I'm seeing this with R3dfox v148.0.2, TCP being used.

Notice that Quad9 (9.9.9.9) is also the system default DNS server of my computer. So I have the feeling that for some reason R3dfox v150.0.1 is not using the DoH server but is falling back to the system default DNS server, even though it's set to Max Protection (network.trr.mode=3) and shouldn't do that.

After some search on the internet, it might be linked with HTTP3/QUIC. I have set network.http.http3.enable to false and it seems to be back to the previous behavior, but that needs more testing.

BUT: this setting already existed in previous versions and set to True but without this UDP behavior. So I wonder why. There must be something else.

I've also found this discussion:
https://www.reddit.com/r/browsers/comments/13capqu/a_guide_on_how_you_can_enable_ech_and_http3_in/

Not sure what to think about it.