r3dfox, a modern Firefox based web browser for Windows Vista, 7, and 8!

[The-10-Pen]

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.

2026-05-06_13-09-27.jpg (155.97 KiB) Viewed 1089 times

[Duke]

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.

[The-10-Pen]

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

[The-10-Pen]

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.

[The-10-Pen]

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.

Untitled.jpg (209.03 KiB) Viewed 1056 times

[Duke]

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

Nice catch, I shoud have tried it before posting.

[The-10-Pen]

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?

[The-10-Pen]

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

[Duke]

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

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]

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.

[Duke]

I believe this commit is a bad idea: Don't unnecessarily upsample audio to 32 bit
https://github.com/Eclipse-Community/r3dfox/commit/8e6a2f27506d2dd589b25ba00591b6fb4d76c0ee

PCM means integer being used while Float means floating-point. The purpose of using 32-bit floating-point is to avoid clipping:
https://en.wikipedia.org/wiki/Clipping_(audio)

Because of a better amplitude, to sum it up:
https://en.wikipedia.org/wiki/Audio_bit_depth#Floating_point

For instance, 32-bit floating-point is the default mode used by Audacity when working on a sound track because you don't have to worry about levels until you save the file at the end when you then reduce the sampling rate, the bit depth, apply dither and use an integer format such as MP3.

Audacity-32float.png (1.48 KiB) Viewed 135 times

So I believe 32-bit floating-point output is used for a good reason and for best compatibility and shoudn't be changed.

[the_r3dacted]

I've found that going over 16 bit for lossy formats results in quality loss, to the point where taking a bit of clipping is better imo. What got me to make this change was when I noticed a meme sounding weird in r3dfox compared to Electron (Chromium). So I went and traced this, and undid the change.

I also did the same for an attempted fork of Audacity, but it kinda died since I expanded the scope of it a bit much, and 2.3.3 does basically everything I need it to anyways.
https://github.com/the-r3dacted/audacity/commits/testbase/

Although I could probably experiment with it and put it behind a pref, but I've already built 150.0.3 so maybe later.

[Duke]

I've found that going over 16 bit for lossy formats results in quality loss

Technically speaking, this is not possible. The extra pad from 16 bits to 32 bits is just filled with zeroes so it can't affect the sound quality in any way.
It's just about the decoded output. Upsampling can't create sounds that don't exist in the first place.

I've already built 150.0.3

Good news, but keep in mind Firefox v151 will be released on next Tuesday the 19 of May

[Duke]

R3dfox v150.0.3 has been released:
https://github.com/Eclipse-Community/r3dfox/releases/tag/v150.0.3

[Duke]

And also R3dfox v140.11 ESR:
https://github.com/Eclipse-Community/r3dfox/releases/tag/v140.11.0