Firefox fails to inflate gzipped resource for loader

I am not sure if this is a bug in three.js or Firefox, but EXRLoader seems to fail under the following conditions. I have not been able to confirm if this happens with other loaders.

• Firefox
• EXRLoader
• Firebase hosted resource served with Content-Encoding: gzip

Cannot parse value for unsupported type: �i"]���w���t ...

It seems like the gzipped content is never inflated/decoded by the browser, as this ugly workaround seems to do the trick:

import * as THREE from 'three';
import { EXRLoader as NativeEXRLoader } from 'three/examples/jsm/loaders/EXRLoader.js';
import pako from 'pako';

export class EXRLoader extends NativeEXRLoader {
	constructor(){
		super();
	}
	load(
		url: string,
		onLoad: ( dataTexture: THREE.DataTexture ) => void,
		onProgress?: ( event: ProgressEvent ) => void,
		onError?: ( event: ErrorEvent ) => void
	): void {
	    const loader = new THREE.FileLoader();
	    loader.setResponseType( 'arraybuffer' );
	    loader.load( url, ( arraybuffer ) => {
		    const fileReader = new FileReader();
		    fileReader.onload = (event) => {
				super.load((event as any).target.result, onLoad, onProgress, onError);
		    }
		    let blob: Blob;
		    try {
		    	blob = new Blob([pako.inflate(arraybuffer as any)]);
		    	console.log('Inflated blob size: '+blob.size);
		    } catch(error) {
		    	blob = new Blob([arraybuffer]);
		    }
		    fileReader.readAsDataURL(blob);
	    }, onProgress, onError );
	}
}

The ‘Accept-Encoding’ header is set automatically by the browser (and cannot be overridden in XMLHttpRequest nor in Axios), so I would assume it was the browsers job do decode it. But Firefox does not decode the content neither as an img.src (maybe because FF doesn’t know .exr) nor if responseType is set to blob or arraybuffer. Safari and Chrome are unaffected.

I’ve seen some old issues on the Firefox bugtracker, but I am unsure what is expected behavior.

EDIT: The XHR spec suggests setting Range: bytes=0 header should force Accept-Encoding: identity, but it seems to make no difference.

Three.js version

• r107

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• macOS

[bovesan]

We all believed this to be a pure browser issue, but I am having problem replicating this in an isolated test: https://bovesan.com/misc/content-encoding/

Unfortunately, my mac is in for service right now, so I am unable to run the test on the same machine as where I first encountered this. Due to this, I have not filed a Mozilla bug yet.

[mrdoob]

@tochoromero Could you please help us by filing a bug to Mozilla and sharing the link here?