Problem with Firefox- Gecko Main pigging CPU after upgrade to 96

The same to me, I see that there is ff v 96.0-2 as a snap package: Install Firefox on Linux | Snap Store , I’ll try to use it next time the problem will appear.

If you’re having trouble with #firefox, try disabling HTTP3 in about:config with the ‘network.http.http3.enabled’ key. After setting this and restarting Firefox everything worked again.

3 Likes

fl4bn4t
Thanks for this. I am curious what tools or line of reasoning you used to arrive at disabling HTTP3? Your remedy and result are interesting. So are you able to tell that HTTP3 in Firefox is the culprit or is it something external to the browser proper. Seems like Moz may have released a buggy version or I wonder if its endemic to Manjaro??
Many thanks…

Alternatively, turn off all telemetry, worked for me.

1 Like

Interesting. My telemetry is already off… Thanks. Something weird no??

EDIT–No it was not. It was in the earlier version but the update re enabled telemetry and remote studies again which I just disabled. Lipstick on the pig.

I had issues with FF not loading websites and the Gecko thread creating high CPU load this morning - but I’m still on FF95.0.2 and the issue seems to have resolved itself now.
Previously neither restarting FF or rebooting would work. Maybe some other issue behind it instead of FF96?

The issue seems to have resolved itself for me too. I’m on 96.0.

Dino-Fossil
I had noticed Gecko porking a week ago and installed Pale Moon because of it. I also saw a problem that seemed to disappear. I also noticed it on 95 on my desktop but it seemed to go back to normal… dont know maybe time for a new browser.

Seems like a buggy update from Mozilla:

3 Likes

Thank you bill_t.

1 Like

I’m just duckduckgo’ed and found https://twitter.com/jbaiter_/with_replies
Refering to 1749908 - Infinite loop in HTTP3 hangs socket thread

:wink:

2 Likes

Good on ya fl4bn4t. I am a little slow on the uptake been up a few hours :slight_smile:
One wonders… after reading some of the thread you found…be interesting as strange as things are…if this were not something in the wild that caused this…
Interesting we get this on 2 different versions in multiple places with no predicted “hard failure” mode…sounds like for most of us that did update it at least worked for a while then kacked no?? So the solution is turning off HTTP3 in about:config. I wonder…with HTTP3 off how much more vulnerable are we…combination maybe of buggy Moz code plus some external actor or place causing HTTP3 to hang.

Narren Welcome to the community. Good distro and great people here on the forum. Welcome !

From the bug report linked above:

Our current suspicion is that Google Cloud Load Balancer (or a similar CloudFlare service) that fronts one of our own servers got an update that triggers an existing HTTP3 bug. Telemetry was first implicated because it’s one of the first services a normal Firefox configuration will connect to, but presumably the bug will trigger with any other connection to such a server. Our current plan is to disable HTTP3 to mitigate until we can locate the exact bug in the networking stack.

Also, the update has apparently been reverted and http3 can be enabled again. Guess there will be an additional fix to FF in the future.

2 Likes

Wonder if the same HTTP3 code is used and enabled in Thunderbird…you know both updated (here at least) same day…Anyone seeing this same Firefox problem on any mobile platforms??

Personally, I have not been affected by these problems so far. After reading the above posts of this topic, I came across the following German-language article.

Mozilla has reported the problems as solved on Twitter. After a reboot the problems should not occur anymore. Mozilla will give more details about the problem at a later time.

https://twitter.com/firefox/status/1481613605934088194

1 Like

Thanks for posting the article Piscatorius. I tried using Google Translator to make sense of it but the website wants one to log in no??

So what does it mean that the problem is “solved”…does that mean we are again operating with the safer HTTP3? Or with the change to about:config we are operating with HTTP2?

Not trying to be difficult but I use my machines for financials…crypto, derivatives, banking and so forth. I also live in Ecuador where(at least where I live) the server techs at the ISP dont know the difference between megabits and megabytes— wild west. So if it appears that I am a little “touchy” about things like browsers and IP Table firewalls and security and keeping machines updated, I am . Firefox says the problem is solved. A good thing if in fact it is “solved”…I also run Debian on one of my machines and as of about 2 PM this afternoon they had an alert and update for Firefox-esr…given that we had the broken update some 24 hours before that I found the esr update interesting as well…wonder if it was part of the same update cycle that got us the garbage it did…

Also read the twitter thread put here only thing I was able to discern from it is " restart ya browser"… someone asked “how many times”…there was no technical information on the Twitter feed at least that I found…
Many thanks…

EDIT- for anyone so curious

If I understood it correctly, there was no recent “update cycle” directly to blame, as it affected multiple Firefox versions (at least 95, 96 and including esr). It seems an older bug related to HTTP3 present in FF for some time that got triggered only now when some server updated the software they were running on.
The temporary fix was therefore to revert the update to the server (or to disable HTTP3).

The real fix for this will likely come at a later time through updates to Firefox, but for now the issue seems to be resolved insofar as you can use the browser without having to worry about lockups.

1 Like

Don’t worry, @expat, the article linked above is free and publicly available for all interested readers. You don’t have to log in or sign up to read it. This feature is intended for subscribers to the site who want to read paid articles marked “heise+”.

By the way, on January 13, 2022, around 6:00 p.m., the article linked above was updated as follows.

Update 6 p.m.: Mozilla has since released a statement about the problems: “Earlier today, Firefox experienced a technical glitch due to a cloud provider changing the default settings, triggering a Firefox HTTP/3 bug. We’ve disabled the configuration change and confirmed that this fixes the issue.” Users who are still experiencing problems should restart their browser.

Since the article was a bit vague on this point, I wrote in my first post that the article stated that Mozilla had reported the problems as solved on Twitter and that after a reboot the problems should accordingly no longer occur. Unfortunately, the German word Neustart is somewhat ambiguous. It can mean both reboot and restart. Only the updated version of the article made it clear to me that Neustart did not mean a reboot of the computer, but a restart of the browser. Translating can be tricky now and then.

[Edit:]

Update:

The error that caused Firefox to fail has been fixed by Mozilla and is said to be due to a case sensitivity error.

:link: Mozilla: Firefox-Fehler von Groß- und Kleinschreibung ausgelöst - 2022-01-14 - Golem.de

[Edit 2:]

Update:

With Firefox 96.0.1, Mozilla has fixed the bug in the Firefox code that caused this problem. Mozilla is already working on a further improvement for an upcoming update, so that Firefox does not end up in an infinite loop again even if such an error occurs.

[Edit 3:]

Update:

Two possible causes of crashes have been fixed, as well as the possibility of the HTTP/3 implementation code entering an infinite loop under erroneous circumstances.