2022-01-13 08:20:53.075936 UTC - [Parent 4106991: Socket Thread]: V/nsHttp Http3Stream::OnReadSegment count=333 state=4 [this=7f6e295623a0]
Another score for automatic updates I guess.
The goal is not to ostracize automatic updates, but to have faster fixes.
Or to separate security updates from feature updates, but I think this ship has long sailed for modern browsers.
That would be my preferred solution. But yes, as you say, that ship has sailed. No reason why it couldn't sail back though.
Multiplying the number of parallel maintenance tracks and associated support costs is not “no reason”.
User is the one who must choose update policy. If user is choosing to not update then it's their own problem and no manufacturer has the right to deside otherwise.
Even if you don't update your browser, the world updates around it
> Telemetry has nothing to do with this, it just happens to be one of the first services with H3 load balancer.
If telemetry really had "nothing to do with" the bug, then the fact that telemetry "just happens to be one of the first services with H3 load balancer" wouldn't trigger the bug.
The question isn't whether "backend services" forms the conceptual essence of the problem - I think we all agree it doesn't.
The question is whether it "happens to be" triggered by backend services.
FWIW I've tried every documented setting, "enterprise" policies, etc. to prevent automatic updates in FF, but nothing seems to stick.
That's s private installation, a company-wide centrally managed might work differently ... but companies normally want to control updates too.
Edit: reading further comments it occurred to me that maybe I'm not affected because I'm not sending any data to Mozilla so I don't hit their HTTP3 load balancer.
I would like to see any source that may exist on it having been silently re-enabled. I know telemetry is anonymized and totally harmless or whatever, but re-enabling it behind my back would feel like such a breach of trust.
Go interview people Mozilla. Less analytical data but you'll end up knowing your users.
Thanks anyone in this thread who helped!
Very frustrating this. Fortunately it isn't a Tuesday or I would have been ready for murder by now.
As I instinctively was already blaming out IT dept for breaking Firefox for some security theater reason I was glad I found the real issue quickly, otherwise I might just have accidentally dropped my laptop out the window
The other thing I noticed was that previously when I looked in taskmgr (windows 10) there were 4 or 5 firefox processes going on -but when I went to close firefox after setting that to false there were not.
I'll close and check again but I'm wondering if simply setting it to false once doesn't allow it to perform some update or something that lets it get back to behaving normally? Like unsticking a log jam?
Forget I said anything. When I restarted and tried to reload HN it hung again. I had to disable network.http.http3.enabled in order come back and edit this comment.
EDIT: my FF version is 91.5.0esr (64-bit) on MacOS.
Many of my colleagues had the same issue today, and they all report that just restarting FF fixes the problem (one restarted the computer itself).