Random errors using dev server in Firefox: "Loading failed for the module" & NS_ERROR_NET_PARTIAL_TRANSFER

[jordanade]

Running VITE v5.4.7 and LARAVEL v10.48.22 (plugin v1.0.5). Running "npm run dev". Using Firefox 130 on Mac. Using about 40 inputs.

Page loads only work roughly half the time. Very often one or more modules will fail to load. Seems to happen more on initial page load but not always. After reloading several times, each with different module loading failures, I am eventually able to get it to work.

Console shows "Loading failed for the module with source ___". Network inspector shows modules failed with NS_ERROR_NET_PARTIAL_TRANSFER error.

Works fine on Chrome.

Anyone have any intuition about what would be causing this? I've already verified that it also happens in Firefox Safe Mode with no extensions.

[jake-low]

You mentioned that you tried in Firefox Safe Mode and the issue persisted, but in my case I was experiencing very similar symptoms and eventually found that uBlock Origin was blocking a dependency of my project from loading. I would have expected this to be fine, and that other chunks of the bundle would still load, but instead it seemed to prevent the entire app from starting. I suspect this has something to do with how Vite's dev server works, because it doesn't happen when my app is deployed in production. Disabling uBlock Origin on the page resolved the issue for me.

Posting this just in case it helps you track down your own issue - maybe Firefox's built-in tracking protection is blocking a script and causing the issue in your case? (not sure if that still runs in Safe Mode)

[linus-jansson]

I think this is not really related to vite but to how firefox handles ES modules.. My lib built with esbuild is not loading half the time on the project im working on. Disabling ublock did nothing on my end and safemode (base firefox) does not do anything. However, moving over to chrome resolves any fetch errors.

Im going to try to push my code to a "production" env to test the same out. Maybe just a localhost thing..

[luketanner]

I think this is not really related to vite but to how firefox handles ES modules

I suspect this isn't correct (or at least, not the full picture) -- I've been encountering these errors too, but notably it also happens intermittently for compiled/bundled .css files, not just .js files.

(For context: running Vite 5.4.6 with Angular 18)

[linus-jansson]

Interesting finding, only encountered it on Firefox on localhost around 40-60% of the time when I was refreshing. No issues fetching css though.

Going to production seems to be no problem at all, and all testing outside of the Gecko driver the issue just doesn't seem to exist at all!

Most odd..

[FlorianHockmann]

I ran into the same problem and I spent some time on making the error reproducible. We use Playwright for our integration tests and can reproduce the problem with our Firefox tests via Playwright.
While trying to make the problem reproducible and removing everything that isn't necessary to produce the problem, I've noticed that the problem only occurs under these circumstances:

1. Vite dev server needs to be used (well, that was already mentioned here by @jordanade)
2. A library needs to be included that is relatively large (in terms of Bytes)
3. Firefox needs to connect to the dev server via HTTPS

I have set up two repositories to reproduce the problem: A library which only includes two images (to reach the needed file size) and a hello world application which uses the library. The repository with the app includes very simply Playwright tests (basically only check that the page can be loaded) and a Docker Compose file to simplify the setup.

If you think that it could help with finding the underlying problem, then I can host the repositories on GitHub of course.

[denilsonsa]

I think it is a good idea to have a reproducible example, so please share your minimal repository, if you still have it.

[HugoPoi]

It's related to HTTP/2.0, I tried disabling in vite config and the problem is gone but it's slower.
I have tried to add maxSessionMemory and peerMaxConcurrentStreams and it doesn't fix it.
I confirm that the problem occur when you load a very large project then some imported files get a NS_ERROR_NET_PARTIAL_TRANSFER.

Vite v5.4.14
NodeJS v20.18.3
Firefox 138.0.1

Workaround

In vite config file

  server: {
    ...
    https: {
      ...
    },
    // ERR_HTTP2_PROTOCOL_ERROR
    // See https://github.com/vitejs/vite/issues/4403
    // Disabling HTTP2 have a performance impact
    proxy: {},
  },

##Related issues

• Random errors using dev server in Firefox: "Loading failed for the module with source" & NS_ERROR_NET_PARTIAL_TRANSFER #18182
• chrome throw ERR_HTTP2_PROTOCOL_ERROR #4403

[jordanade]

I tried doing proxy: {} but the problem remains. Now running Vite 7.3.0.

[denilsonsa]

I've been having this issue for the past year or so. I'm working on a large project, so the collection of all JavaScript files is very large.

Until the beginning of the year, whenever Firefox would show an empty page (due to this bug), I could just refresh a few times and it would eventually load everything. But in the recent Firefox version(s), I cannot load my page. Even after trying Ctrl+R multiple times, some of the files still fail to load. (I noticed in 149, but potentially also happening on 148.)

I can confirm the findings from this comment. This buggy behavior happens on vite dev server over HTTPS.

This bug is gone if I remove https: {…} from vite config.

Adding proxy: {} does absolutely nothing.

[logankaser]

Can reproduce on 7.3.1. Currently forced to use Chrome, which seems to retry on what seems to be a server-side HTTP/2 related failure

[logankaser]

Smells like a write timeout inside Vite that is too aggressive, but unable to find the code thus far

[jordanade]

I can confirm this still happens with Vite 8. Gemini Flash suggested these config changes that seemed to help resolve this for me:

import dns from 'dns';
dns.setDefaultResultOrder('verbatim'); // Force consistent IPv4/IPv6 ordering

export default defineConfig({
    // ...
    server: {
        host: '127.0.0.1',             // Force IPv4 to prevent resolution race conditions
        hmr: {
            host: 'local-domain.d',         // Match the Laravel/Valet certificate domain exactly
        },
        origin: 'https://local-domain.d:5173', // Ensure absolute module paths use the correct Laravel/Valet domain
    },
    plugins: [
        // ... other plugins
        /**
         * Firefox Fix Plugin
         * Injects critical HTTP/2 session performance tweaks into the 
         * automatically detected Laravel/Valet certificates.
         */
        {
            name: 'firefox-fix',
            enforce: 'post',            // Ensure this merges after certificate detection
            config: () => ({
                server: {
                    https: {
                        maxSessionMemory: 2000,         // Increase HTTP/2 session memory to 2GB
                        peerMaxConcurrentStreams: 500, // Increase concurrent module delivery capacity
                    },
                },
            }),
        },
    ],
    // ...
});

[jordanade]

Gemini Flash summarizes the issue thusly:

The underlying issue is a "perfect storm" of three factors specific to how Firefox handles high-concurrency local development environments. Here is a summary of the root causes:

1. HTTP/2 Stream Exhaustion

Vite serves your application as hundreds of tiny, individual ES modules. To be efficient, Firefox attempts to handle all these requests over a single HTTP/2 connection.

• The Problem: Firefox has a very strict internal "budget" for how many concurrent requests (streams) it will track per connection. When Vite bursts 100+ modules at once, Firefox often hits this limit and simply "drops" the remaining requests, leading to the random NS_ERROR_NET_PARTIAL_TRANSFER or "Loading failed" errors you were seeing.
• The Fix: By increasing maxSessionMemory and peerMaxConcurrentStreams, we tell the Vite server to offer a much larger "budget" to Firefox, preventing the drop.

2. DNS "Dual-Stack" Oscillation

Since Node.js v17, the system attempts to resolve localhost (and custom domains like local-domain.d) to both IPv4 (127.0.0.1) and IPv6 (::1).

• The Problem: Firefox has an algorithm called "Happy Eyeballs" that tries both addresses simultaneously and picks the "winner." In local dev environments, this often leads to a race condition where Firefox tries to load a module over IPv6 while Vite is only listening on IPv4 (or vice versa), causing intermittent connection resets.
• The Fix: Setting dns.setDefaultResultOrder('verbatim') and forcing host: '127.0.0.1' locks everything into a single, predictable IPv4 path.

3. Certificate/Origin Mismatch

Firefox is significantly stricter than Chrome regarding the Origin of ESM modules when using self-signed certificates.

• The Problem: If a module is requested via a relative path but the browser's internal "HMR host" or "Origin" is slightly ambiguous (due to how Valet proxies the connection), Firefox may pause the module load to re-verify the certificate/handshake for that specific "new" origin, which often fails during the chaos of a page load.
• The Fix: Explicitly defining server.origin and matching the hmr.host to your certificate domain (local-domain.d) gives Firefox a single, absolute, and trusted source for every request, eliminating the need for speculative handshaking.

[denilsonsa]

We must not trust LLM output blindly. So I spent some time double-checking that.

I can confirm that:

• On the project I'm working on, the failure happens after around 90 requests. (How do I know? I saved the entire network log as a HAR file, opened it in a text editor, and manually inspected the JSON object.)
• Node's http2.createServer indeed has maxSessionMemory (default = 10 megabytes) and peerMaxConcurrentStreams (default = 100).

I CANNOT confirm:

• Resolving localhost to both IPv4 and IPv6. I have not seen this happen, and I don't know how to check for that.
• Certificate/Origin mismatch. I don't see any certificate error from my side.
• I did not try dns.setDefaultResultOrder. I've wasted too much time on AI slop already, and this sounds very unrelated.

And I can REFUTE:

• Adding maxSessionMemory: 500, peerMaxConcurrentStreams to my https configuration inside my server configuration inside vite configuration file did NOT resolve the issue. (Note that I added them directly to those config entries, instead of creating a plugin for it.)
• Likewise, adding host or origin did NOT resolve the issue.
• Adding both simultaneously also did not change anything.

Additionally, those comments about Laravel/Valet are completely off-topic.

Hi! I'm a human developer! I double-check AI slop so you don't have to. (Jokes aside, I appreciate you were trying to help, but in my experience so far the LLMs have only generated slop. So I'm personally very skeptical and critical of AI-generated output.)

[jordanade]

I appreciate your research on this, much of which is above my pay grade. I've been dealing with this for multiple years now and was just ecstatic to have something that worked for me, and so it was my duty to share. I will try deleting some of the more dubious bits out of my config and see if the fix still holds.

[ottosson]

Just want to chime in on this. Just saw this when updating from Vite 5.4 to Vite 8.1. Very unfortunate as it breaks development in Firefox and I have to switch to Chrome for most of the work.

My environment:

Vite: 8.1.0 (Rolldown 1.1.3 as the default bundler)
@vitejs/plugin-react: 6.0.3
vite-plugin-svgr: 5.2.0
React / React-DOM: 18.3.1
Node: 24.11.1
Package manager: yarn 4.12.0
OS: Windows 11 Enterprise 23H2 (build 22631)
Browser: Firefox 151.0.4

Dev server config (relevant bits):

server: {
port: 44412,
https: getHttpsConfig(), // ASP.NET dev cert → server runs over HTTP/2
},
plugins: [react(), svgr()],

Module-graph size: ~2,282 modules (per production build)

[logankaser]

I migrated to rsbuild and it handles it fine (also faster). You might want to consider that.

[ottosson]

Thanks, that's not a bad tip. For this project I can't really do that though. Will definitely consider for the next though.

[EverStarck]

i had this issue just on firefox, dumbest thing in the world, check your extensions, if you use ublock origin probably it is blocking it

[incutonez]

Migrated from Vite 7.1.x (no issues) to 8.3.4, and I'm seeing this issue so much in Firefox 158.0.1 (64-bit). Sometimes I'm lucky, and a hard refresh will fix it, but most of the times, I get 1 to dozens of Loading failed for the module with source... warning. It does look like it only shows if I make a change and then refresh the page (I've turned off HMR)... if I haven't made a change and refresh, all's well. It seems like there's something funky with the vite caching, which I would attribute to rolldown, since that's now the default in 8, right?

It's also good to note that I maintain an internal component library, and when I'm in an app consuming that library, that's when I see this issue. However, when I'm in the test harness app for the component library (it's not bundled at this point), then I don't see the issue. In our internal library, we use a lot of barrel files, and I'm wondering if that's causing the issue here.