Performance degradation in Firefox 130 when accessing localhost and external websites

[qrp73]

After upgrading to Firefox version 130, I noticed significant performance issues compared to version 128. Pages, including those hosted on a localhost server, experience intermittent hangs, with some pages failing to load entirely. The browser sometimes gets stuck with the loading indicator spinning indefinitely, and no requests are sent to the server.

• Firefox fails to send any HTTP request to the local server (no connection logs on the server).
• The browser remains stuck in a loading state with no traffic being sent.
• When issue happens, there is no request packets are captured in Wireshark from Firefox.
• Chromium browser under the same conditions works ok with no issue.
• Disabling DNS over HTTPS did not resolve the issue (at least, no visible improvement in real-time).
• Issue appears to improve slightly when switching the server to HTTP 1.0, but the problem persists intermittently.
• Chromium has no issues accessing the same local server, confirming that this is isolated to Firefox.

Notes: The issue is noticeable even with external websites, though I initially attributed it to internet connectivity issues. The problem became more apparent when testing with localhost, where no external factors could influence the connection. The behavior change was observed immediately after the upgrade to version 130.

I also noticed that switching the POST response from chunked mode to regular mode on web server side might resolve the issue, though I can't say for sure since the problem is floating and cannot be consistently reproduced.

At a glance, it looks like an issue in the Firefox network stack code. I suspect this might be related to DNS, as when the issue occurs, the browser doesn't even send some of the requests that it should be sending.

I want to emphasize that while reproducing the issue in Firefox, I ran Chromium in parallel, and it worked without any problems, whereas Firefox just hangs when refreshing the page or opening the same site. It can be definitively stated that this issue is not related to cookies, as the problem occurred on a local server that doesn't use cookies. It might be some issue with request caching.

[cillian64]

Thanks for the report. I've just done some testing with Firefox 130.0-1+rpt7 and using python3 -m http.server as a server on localhost. It worked perfectly for me, everything loaded instantly and correctly. Can you reproduce the problem using python3 -m http.serveras the server with no other changes or customisation?

Our downstream Firefox package only has minimal changes from the official Firefox releases (specifically making widevine work, a graphics buffer allocation fix, and a couple of compilation-issue patches. There are also a few patches we inherit from Debian's Firefox packages) so this is very likely not a problem specific to the Raspberry Pi Firefox package. I recommend reporting this on the Mozilla bug-tracker as the issue will go to someone with some expertise in the network code. (I've always found people extremely helpful on the mozilla tracker if you're happy to try out their suggestions/diagnostics)

If you can reproduce the problem somewhat reliably with official Mozilla builds then you could use mozregression to work out the specific commit which introduced the breakage, at which point I'm sure someone at Mozilla would be able to fix this. I believe mozregression only started including aarch64-linux builds relatively recently so you might need to do it with x86_64 builds.

[qrp73]

Thanks for the report. I've just done some testing with Firefox 130.0-1+rpt7 and using python3 -m http.server as a server on localhost. It worked perfectly for me, everything loaded instantly and correctly. Can you reproduce the problem using python3 -m http.serveras the server with no other changes or customisation?

Yes, I encountered this issue exactly using python3 http.server with HTTP protocol. I was using it to simulate a local server for debugging code. However, I used different server tweaks in the code because I couldn’t get chunked POST responses to work properly in either Chromium and Firefox. The key changes included switching the protocol to HTTP/1.1 and varying the way I formatted the headers for the chunked response.

Eventually, the issues became persistent, so I reverted to using the default HTTP protocol. I was able to implement it in that way to get both browsers to accept the response consistently. But what I notice, is that after switching back to the default HTTP protocol, the problem with Firefox occurred much less frequently.

I also encountered several instances in the js debugger (browser console) where the server successfully processed a request and sent a response, but the browser didn’t see the response and continued to wait for it. I was able to reproduce this at least five times in a row.

However, it's important to note that the problem is not limited to localhost, it occurs with any site on the internet. The issue is floating and unpredictable, as I cannot reliably reproduce it.

When it happens the browser's GUI remains responsive, so it appears to be related to the network stack code. As I mentioned earlier, I checked it with Wireshark, and it turned out that Firefox just doesn't establish a connection at all, even though graphically it shows that the request is being processed...

Previous versions didn’t exhibit this behavior. I can’t say for sure whether it started with version 129 or 130, but version 128 definitely worked fine.

The issue is quite unusual. I tried to investigate it using Wireshark, but it turned out that when this occurs, the browser doesn’t even send the requests. Something is malfunctioning within the browser, and it's unclear what exactly. This typically happens in the middle of loading a large webpage—some requests are completed, but then something goes wrong, and the browser stops sending further requests, although it graphically shows as sending them and waiting for a response. Wireshark clearly shows that only part of the expected requests for the page load are actually sent.

I also noticed very strange behavior when modifying the code generating POST responses on the server. It seemed that Firefox was retrieving responses from the cache, even though it was making requests and receiving responses. Initially, I couldn’t figure out why the code wasn’t working in Firefox, but after restarting the browser, it suddenly started working, despite no changes being made on the server side.

At first, I suspected packet routing issues, but adding the route with sudo ip route add 127.0.0.0/8 dev lo didn’t resolve the problem.

I also occasionally encountered strange issues with websites failing to load, even though they worked fine in Chromium.

[lurch]

Is it possible that there's some kind of filesystem corruption on your SD card? Are you able to reproduce this problem on a freshly-written Bookworm image?

[qrp73]

Some new findings: this issue can be reproduced if you click the 'Reload' button on Firefox in a loop for a heavy page. It goes into a strange state where you click the Reload button, but it doesn't send a request to the server anymore.

Steps to reproduce:

1. Open page in Firefox v130.0 (64-bit): https://cpulator.01xz.net/?sys=arm
2. Wait for page load completed
3. Click on Firefox Reload button in a loop with about 1 sec interval (don't wait until page load complete)
4. Do step 3 until page become non responsive, usually it take about 3-10 clicks
5. Click On Reload button again

Expected result: the page is reloaded with no issue

Actual result: nothing happens, the browser even don't send request to the server

Additional info: there are no log messages about errors when you run Firefox from the console and no errors in dmesg. If you open dev tools (F12) before reproducing the issue, you can see that when the issue occurs, the dev tools console works fine, but the page becomes non-responsive, and no requests are sent to the server.

The same issue happens for other sites as well as for a site hosted on localhost. The Chomium browser don't have this issue.

[cillian64]

Good reproducer, I've just managed to immediately see this issue on my Pi5. But I can also reproduce it on my amd64 debian laptop, so it's not Raspberry Pi specific. Please could you report this on https://bugzilla.mozilla.org/ as they will be much more able to help. With this simple and reliable reproducer I'm certain that they'll get this fixed quickly.

[cillian64]

I can also reproduce this with Firefox 131.0 on Windows 10. Could you link me to the BMO issue when you make it, I'm curious to follow along and see what causes this.

Also interesting is that the whole tab is totally dead - even if you try to navigate to a different URL, nothing happens. But when you switch a different tab it's just fine.

[qrp73]

I have no account on bugizlla and I'm too lazy to register. Could you please add it?

[qrp73]

Also interesting is that the whole tab is totally dead - even if you try to navigate to a different URL, nothing happens. But when you switch a different tab it's just fine.

it is not dead, if you open dev-tools (F12) before reproduce it, you can continue use dev-tools on that tab. But page area is really dead and don't respond. I also was seen the same issue which happens in the middle of page load...

[cillian64]

Ok, reported upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1923881

[qrp73]

thanks

I read the issue on bugzilla and as Andrew Sutherland said:

I see a sync XHR that seems to be waiting for the server to respond fired during the unload event.

I can also say that I had many similar issues when debugging my custom XHR response format on the server side.

Therefore, it is quite likely that the problem is somehow related to the implementation of XHR in Firefox's code.

He also wrote:

An interesting question is whether the site has some kind of anti-DoS protection that means if you keep hitting reload it views you as an attacker and starts tarpitting your connections.

But I reproduced this bug with a localhost running on Python3 using http.server. There is no anti-DoS protection, so it doesn't depend on the server not responding.

In fact, Firefox simply doesn't send the request to the server at all, which was confirmed with a Wireshark capture.