Any hope for Firefox support?

[mindplay-dk]

Is there any chance of getting support for Firefox? via some hack or workaround?

My own conclusion was that there are too many cross-browser issues with streams in Firefox and Safari, and just go with XmlHttpRequest and business as usual, but it looks like you're pulling it off. 😄

Do you know if Firefox is working on the streams issue? or is that where this gets stuck?

[webJose]

AFAICT, the functionality is based on ReadableStream and TransformStream. I have never tested in Firefox, but the caniuse website says Firefox supports both. Is it not working?

I don't have it installed. If you have it, test this Svelte REPL. Just note that the default 50MB file set up doesn't seem to exist anymore. You'll have to provide a new file URL. The code has this 1GB file commented out, which last time I checked was working: https://ash-speed.hetzner.com/1GB.bin

[sk-pub]

Progress tracking only works for responses in Firefox.

Unfortunately, request progress tracking won't work in Firefox until it supports ReadableStream as Request.body in fetch API.

[webJose]

Wow, that FF issue is 8 years old, and 6 months ago they said "no plans to work on this", and then later started talking about supporting it only for HTTP/2.

I pity FF users.

[mindplay-dk]

FF is the new IE. 😌

[KonnorRogers]

AFAICT, the functionality is based on ReadableStream and TransformStream. I have never tested in Firefox, but the caniuse website says Firefox supports both. Is it not working?

I don't have it installed. If you have it, test this Svelte REPL. Just note that the default 50MB file set up doesn't seem to exist anymore. You'll have to provide a new file URL. The code has this 1GB file commented out, which last time I checked was working: https://ash-speed.hetzner.com/1GB.bin

Hi there, sorry for barging in, saw the thread on BSky and figured I'd pop in since this has annoyed me for like 5+ years...

More specifically than the TransformStream and ReadableStream bodies, the browser implementation of fetch needs to support duplex: "half" to work to properly track request progress.

(which is why this feature check exists:

fetch-api-progress/src/trackRequestProgress.ts

Lines 24 to 39 in 622330b

	const supportsRequestStreams = (() => {
	let duplexAccessed = false;
	const hasContentType = new Request("https://teil.one", {
	body: new ReadableStream(),
	method: "POST",
	// @ts-expect-error duplex is not supported in type definitions yet
	get duplex() {
	duplexAccessed = true;
	// https://developer.chrome.com/articles/fetch-streaming-requests/#half-duplex
	return "half";
	}
	}).headers.has("Content-Type");
	return duplexAccessed && !hasContentType;
	})();

)

Both caniuse and MDN report this as not supported in any version of Safari or Firefox.

https://caniuse.com/?search=duplex

https://developer.mozilla.org/en-US/docs/Web/API/Request#browser_compatibility

WebKit has at least stated they approve for streamable uploads it and it seems some people are working on it.

WebKit/standards-positions#24 (comment)

No word from Firefox if they have any implementations in the works.

Wow, that FF issue is 8 years old, and 6 months ago they said "no plans to work on this", and then later started talking about supporting it only for HTTP/2.

@webJose it seems that HTTP2+ restriction also exists in Chrome and is deemed too much of a backwards compatibility risk. Its talked about in the fetch-streaming-requests blog post on Google's blog here:

https://developer.chrome.com/docs/capabilities/web-apis/fetch-streaming-requests#doesnt_work_on_http1x

Also worth noting, even Chrome does not support duplex: "half" streaming on HTTP/1.x due to this risk.

[jakearchibald]

I just happened across this thread. Streaming requests/responses shouldn't be seen as a way to measure progress - they're not reliable https://jakearchibald.com/2025/fetch-streams-not-for-progress/.

Streaming is for getting/producing the body in chunks.

[webJose]

Interesting. I'll read later. It sounds weird to me because, at least for download, I see the progress bar (based on the stream) quite in sync with the data reported by developer tools.

[jakearchibald]

https://jakearchibald.com/2025/fetch-streams-not-for-progress/#but-theyre-not-ideal-for-measuring-download-progress covers the issues particular to download streams

[webJose]

Ok, I read.

In a nutshell:

1. Compressed responses should be treated as unknown length.
2. Upload progress is to be interpreted as "delivered to the internals of the environment" (browser, Electron, etc.).
3. A new API might be coming. That's great.

Other than this, I don't see much of a problem. This package can be amended for point 1 above. Then educate people about point 2. That's it. Or am I mistaken?

[jakearchibald]

The current system of measuring upload progress is unreliable, and could introduce future web compat issues, as detailed in the article. But if you don't see that as a problem, then fair enough. In terms of interop, Firefox and Safari may delay shipping request streaming until we have progress events, to reduce the chance of compat issues caused by libraries like this.

https://github.com/teil-one/fetch-api-progress?tab=readme-ov-file#supported-platforms - the readme claims to support progress for requests in Safari. I think this is an error. Safari doesn't support fetching requests with stream bodies.

[webJose]

Yes, I personally don't see much of a problem. The future is not here yet, and the current way this package does things is the only way of doing it.

Once/if the new API exposes download/upload progress natively, we'll embrace it with open arms.

If you have spotted a problem in the README, feel free to log an issue or contribute a pull request. Cheers!

[sk-pub]

@jakearchibald , I covered the compression concern in this library. See https://github.com/teil-one/fetch-api-progress/blob/main/src/trackResponseProgress.ts#L37

[jakearchibald]

Ah yes, that's a reasonable work-around.